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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



The present document is the first part of a multi-part conformance specification valid for 3GPP Release 8. 3GPP TS 
36.523-2 [18] contains a pro-forma for the Implementation Conformance Statement (ICS) and an applicability table, 
indicating the release from which each test case is applicable. 3GPP TS 36.523-3 [19] contains a detailed and 
executable description of the test cases written in a standard testing language, TTCN, as defined in ISO/IEC 9646. 

For at least a minimum set of services, the prose descriptions of test cases will have a matching detailed test case 
implemented in TTCN [19]. 

The present document may contain descriptions of tests for additional services, but these tests may not have matching 
TTCN test cases. 

The present document will not contain any tests on the USIM, or the interface between the UE and the USIM. These 
tests are documented elsewhere. 
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Scope 



rd , 



The present document specifies the protocol conformance testing for the 3 Generation E-UTRAN User Equipment 
(UE). 

This is the first part of a muhi-part test specification. The following information can be found in this part: 

the overall test structure; 

the test configurations; 

the conformance requirement and reference to the core specifications; 

the test purposes; and 

a brief description of the test procedure, the specific test requirements and short message exchange table. 
The following information relevant to testing could be found in accompanying specifications: 

the default setting of the test parameters [18]; 

the applicability of each test case [19]. 
A detailed description of the expected sequence of messages could be found in the 3"* part of this test specification. 
The Implementation Conformance Statement (ICS) pro-forma could be found in the 2""* part of the present document. 
The present document is valid for UE implemented according to 3GPP Release 8. 
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[25] 3GPP TS 36.509: "Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal 

Terrestrial Radio Access Network (E-UTRAN); Special conformance testing functions for User 
Equipment (UE)". 



3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in TR 21.905 [1] and the following apply. A 
term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905 [1]. 
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example: text used to clarify abstract rules by applying them literally. 
Floor: Floor(x) is the largest integer smaller than or equal to x. 
Ceil: Ceil (x) is the smallest integer larger than or equal to x. 



3.2 



Abbreviations 



For the purposes of the present document, the abbreviations given in TR 21.905 [1] and the following apply. An 
abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in 
TR 21.905 [1]. 



ENB 

FDD 

FFS 

ICS 

ROHC 



Evolved Node B 

Frequency Division Duplex 

For Further Study 

Implementation Conformance Statement 

RObust Header Compression 



4 Overview 

4.1 Test iVIethodology 

4.1 .1 Testing of optional functions and procedures 

Any function or procedure which is optional, as indicated in the present document, may be subject to a conformance test 
if it is implemented in the UE. 

A declaration by the apparatus supplier (ICS) is used to determine whether an optional function/procedure has been 
implemented. 

4.1 .2 Test interfaces and facilities 

Detailed descriptions of the UE test interfaces and special facilities for testing will be provided in [6 or FFS]. 



4.2 Implicit Testing 



For some 3GPP signalling and protocol features conformance is not verified explicitly in the present document. This 
does not imply that correct functioning of these features is not essential, but that these are implicitly tested to a 
sufficient degree in other tests. 



5 Reference Conditions 

The reference environments used by all signalling and protocol tests will be specified in TS 36.508 [18]. Where a test 
requires an environment that is different, this will be specified in the test itself. 



5.1 Generic setup procedures 



A set of basic generic procedures for radio resource signalling, and generic setup procedures for layer 3 N AS signalling 
will be described in TS 36.508 [18]. These procedures will be used in numerous test cases throughout the present 
document. 
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Idle Mode Operations 



6.0 



Introduction 



6.0.1 UE pre-test condition 

Unless otherwise stated in the method of test, in all of the tests of this clause the UE is equipped with a USIM 
containing default values. The USIM is in the idle updated state in the default tracking area with a GUTI assigned at the 
beginning of each test. More details regarding USIM default values are FFS. 

6.0.2 Cell levels 

The cells shall be configured such that Srxlev>0. The actual values for Qrxlevmin, Qrxlevminojfset and the measured 
cell Rx level (RSRP) are TBD. The definition of the "high quaUty" E-UTRAN cell is TBD in TS 36.304. 

6.0.3 Test method 

In order to check that the UE is camping to a new cell, this cell belongs to a tracking area which was not in the list of 
tracking areas previously allocated to the UE. In the test case description, a test step will be included with a question 
such as "Does the UE initiate a random access on cell X?". If such a random access is detected by the SS, the SS shall 
allow the UE to do a complete successful tracking area update procedure as specified in table 6.1, before executing the 
next step of the test procedure description. 

Table 6.0.3.2: Tracking area update behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


2 


The UE sends an RRCConnectionRequest 
message to perform signalling? 


— > 


RRCConnectionRequest 


- 


- 


3 


SS transmit a RRCConnectionSetup message. 


<— 


RRCConnectionSetup 


- 


- 


4 


The UE transmits a TRACKING AREA 
UPDATE REQUEST message (included in 
RRCConnectionSetupComplete message) 
order to update the registration of the actual 
tracking area. 


— > 


TRACKING AREA UPDATE 
REQUEST 






5 


The SS transmits a SecuhtyModeCommand 
message to activate AS security. 


<— 


SecuhtyModeCommand 


- 


- 


6 


The UE transmits a SecurityModeComplete 
message and establishes the initial security 
configuration. 


— > 


SecurityModeComplete 






7 


SS responds with TRACKING AREA UPDATE 
ACCEPT message. 


<— 


TRACKING AREA UPDATE 
ACCEPT 


- 


- 


8 


The SS transmits a RRCConnectionRelease 
message to release RRC connection and 
move to RRC IDLE. 


<— 


RRCConnectionRelease 







Note: The periodic tracking area updating timer T3412 is deactivated by default during the attach procedure (TS 
36.508 clause 4.7.2). 

Note: The SS does not initiate authentication and NAS SECURITY MODE COMMAND are not performed 
(reuse of keys allocated during the attach procedure). 

6.0.4 PLMN and TAG 

The PLMN numbers indicated in table 6.1 are used in test cases to associate a cell with an MCC and MNC for that cell. 
If no PLMN is explicitly specified, the default value is PLMN 1 . 
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Table 6.0.4-1 : Tracking Area Identity (TAI) in System Information Block Type 1 
broadcast on the BCCH (E-UTRAN) 



PLMN 


MCC1 MCC2 


MCC3 


MNC1 


MNC2 


MNC3 


TAC 


1 





1 







Not present 


X 


2 





2 


1 




Not present 


X 


3 





3 


2 




Not present 


X 


4 





4 


3 




Not present 


X 


5 





5 


4 




Not present 


X 


6 





6 


5 




Not present 


X 


7 





7 


6 




Not present 


X 


8 





8 


7 




Not present 


X 


9 





9 





2 


Not present 


X 


10 


1 





1 


2 


Not present 


X 


11 


1 


1 


2 


2 


Not present 


X 


12 


1 


2 


3 


2 


Not present 


X 


NOTE: 'x' denotes any value. 



Editor's note: The number of PLMN's and the values for MCC and MNC in Table 6.1 are FFS. 

Editor's note: The Location Area Information (LAI) for UTRA and GSM could be re-used from TS 34.123-1 clause 
6. 

6.0.5 Other 

Editor's note: Other generic [FFS] information for idle mode testing to be added in this clause is as follows: 

Default values of the system information fields for different methods and lEs specific to idle mode; 

Requirements for FDD and TDD cells (check TS 36.331) in order for the UE to be able to identify a new 
detectable cell and camp on it (minimum channel power levels); 

Generic test behaviour in case of combined E-UTRA/UTRA/GSM/HRPD/lxRTT tests: indication of access 
technology; 

Test channel numbers used in test cases to associate a cell with a frequency for that cell. If no channel is 
explicitly specified, the default value is Test Channel 1 . The frequencies and RF signal levels for UTRA and 
GSM could be re-used from TS 34.123-1 clause 6. The frequencies and RF signal levels for E-UTRA test 
channels shall be based on TS 36.508 clauses 4.3.1.1, 4.3.1.2 and 4.3.4. 



6.1 In a pure E-UTRAN environment 

6.1.1 PLMN Selection 

6.1 .2 Cell Selection and Reselection 



6.1.2.2 

6.1.2.2.1 
(1) 



Cell selection, Qrxlevmin 

Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { a cell fulfils all requirements for a suitable cell except the cell selection criteria 
which are not fulfilled {S<0) } 

then { the UE does not consider the cell suitable and no camping on this cell can take place 

} 

(2) 

with { UE in E-UTRA RRC_IDLE state } 
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ensure that { 

when { a cell fulfils all requirements for a suitable cell including the cell selection criteria 
for a cell which are also fulfilled {S>0) } 

then { the UE considers the cell suitable and camps on it } 
} 

6.1.2.2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS36.300, clause 10.1.1.1 and 
TS 36.304, clause 4.1, 5.1.2.2, 5.2.3.1, 5.2.3.2 and 5.2.8. 

[TS 36.300, clause 10.1.1.1] 



Cell selection: 

- The UE NAS identifies a selected PLMN and equivalent PLMNs; 

The UE searches the E-UTRA frequency bands and for each carrier frequency identifies the strongest cell. It 
reads cell system information broadcast to identify its PLMN(s): 

The UE may search each carrier in turn ("initial cell selection") or make use of stored information to shorten the 
search ("stored information cell selection"). 

The UE seeks to identify a suitable cell; if it is not able to identify a suitable cell it seeks to identify an 
acceptable cell. When a suitable cell is found or if only an acceptable cell is found it camps on that cell and 
commence the cell reselection procedure: 

A suitable cell is one for which the measured cell attributes satisfy the cell selection criteria; the cell PLMN is 
the selected PLMN, registered or an equivalent PLMN; the cell is not barred or reserved and the cell is not part 
of a tracking area which is in the list of "forbidden tracking areas for roaming"; 

An acceptable cell is one for which the measured cell attributes satisfy the cell selection criteria and the cell is 
not barred; 



[TS 36.304, clause 4.1] 



When a UE is switched on, a public land mobile network (PLMN) is selected by NAS. For the selected PLMN, 
associated RAT(s) may be set [5]. The NAS shall provide a list of equivalent PLMNs, if available, that the AS shall use 
for cell selection and cell reselection. 

With the cell selection, the UE searches for a suitable cell of the selected PLMN and chooses that cell to provide 
available services, further the UE shall tune to its control channel. This choosing is known as "camping on the cell". 

The UE will, if necessary, then register its presence, by means of a NAS registration procedure, in the tracking area of 
the chosen cell and as outcome of a successful Location Registration the selected PLMN becomes the registered PLMN 
[5]. 



[TS 36.304, clause 5.1.2.2] 

The UE shall scan all RF channels in the E-UTRA bands according to its capabilities to find available PLMNs. On each 
carrier, the UE shall search for the strongest cell and read its system information, in order to find out which PLMN(s) 
the cell belongs to. If the UE can read one or several PLMN identities in the strongest cell, each found PLMN (see the 
PLMN reading in [3]) shall be reported to the NAS as a high quality PLMN (but without the[quality measure TBD]), 
provided that the following high quality criterion is fulfilled: 

[include definition of a "high quality" E-UTRAN cell here] 

Found PLMNs that do not satisfy the high quality criterion, but for which the UE has been able to read the PLMN 
identities are reported to the NAS together with the [quality measure TBD]. The quality measure reported by the UE to 
NAS shall be the same for each PLMN found in one cell. 
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Once the UE has selected a PLMN, the cell selection procedure shall be performed in order to select a suitable cell of 
that PLMN to camp on. 

[TS 36.304, clause 5.2.3.1] 

The UE shall use one of the following two cell selection procedures: 

a) Initial Cell Selection 

This procedure requires no prior knowledge of which RF channels are E-UTRA carriers. The UE shall scan all 
RF channels in the E-UTRA bands according to its capabilities to find a suitable cell. On each carrier frequency, 
the UE need only search for the strongest cell. Once a suitable cell is found this cell shall be selected. 



[TS 36.304, clause 5.2.3.2] 

The cell selection criterion S is fulfilled when: 



Srxlev > 



Where: 



Srxlev = Qrxievmeas - (Qrxlevmin - Qrxlevminoffset) - Pcompensation 



Where: 

the signalled value QrxlevminOffset is only applied when a cell is evaluated for cell selection as a result of a periodic 
search for a higher priority PLMN while camped normally in a VPLMN [5]. During this periodic search for higher 
priority PLMN the UE may check the S criteria of a cell using parameter values stored from a different cell of this 
higher priority PLMN. 



Srxlev 


Cell Selection RX level value (dB) 


Urxlevmeas 


Measured cell RX level value (RSRP). 


Qrxlevmin 


Minimum required RX level in the cell (dBm) 


Qrxlevminoffset 


Offset to the signalled Qrxlevmin taken into account in the Srxlev evaluation 
as a result of a periodic search for a higher priority PLMN while camped 
normally in a VPLMN [5] 


Pcompensation 


[FFS] 



[TS 36.304, clause 5.2.8] 

In this state, the UE shall attempt to find an acceptable cell of any PLMN to camp on, trying all RATs that are 
supported by the UE and searching first for a high quality cell, as defined in subclause 5.1.2.2. 

The UE, which is not camped on any cell, shall stay in this state until an acceptable cell is found. 
6.1.2.2.3 Test description 

6.1.2.2.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

- Cell 1 is a cell with TAIl (PLMNl + TACl) where PLMNl is part of the Equivalent PLMN Hst: 

- Cell 1 is not a CSG cell, Srxlevceii i<0 
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Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 



6.1.2.2.3.2 



Test procedure sequence 



Table 6.1.2.2.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while row marked "Tl" is to 
be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 6.1.2.2.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Celll 


Remarl< 


TO 


Cell-specific RS 
EPRE 


dBm 


-95 


The power level value is such to satisfy SrxlevCell 1 < but the UE is 
able to read the PLMN identity 


Qrxlevmin 


dBm 


-84 




Qrxlevminoffset 


dB 







Pcompensation 


dBm 





Still FFS in the core specification 


Tl 


Cell-specific RS 
EPRE 


dBm 


-75 


The power level is such that SrxlevCell 1 > 


Note: The downlink signal level uncertainty is specified in TS 36.508 section 4.3.4.1 



Editors note: The power levels will be revisited when the definition of a high quality cell and Pcompensation will be 
completed in TS 36.304. 



Table 6.1.2.2.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


Check: Is there any random access request 
from the UE on Cell 1 within the next 60 s? 


- 


- 


1 


F 


3 


SS re-adjusts the cell-specific reference signal 
level of Cell 1 level according to row "Tl" in 
table 6.1.2.2.3.2-1. 










4 


Check: Is there any random access request 
from the UE on Celll? 


- 


- 


2 


P 



6.1 .2.2.3.3 Specific message or IE contents 

Table 6.1.2.2.3.3-1 SystemlnformationBlockTypel ior ceW 1 (preamble) 



Derivation Path: 36.508 clause 4.4.3.2 | 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockTypel ::= SEQUENCE { 
cellSelectionlnfo SEQUENCE { 
q-Rxlevmin 

} 

schedulinglnformation ::= SEQUENCE (SIZE 
(1 ..maxSI-Message)) OF SEQUENCE {} 

} 


-42 (-84 dBm) 

Combination 1 in TS 
36.508 section 4.4.3.1.1 


Only SIB2 and 
SIB3 are 
transmitted 
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6.1 .2.3 Cell selection / intra E-UTRAN / serving cell becomes non-suitable (S<0, 

barred) (intra frequency) 

6.1 .2.3.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { the serving cell becomes non-suitable {S<0)and there is a suitable neighbour cell {S>0) } 
then { UE selects the suitable neighbourgh cell } 

(2) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { the serving cell becomes barred and there is a suitable neighbour cell} 
then { UE selects the suitable neighbourgh cell } 
} 

6.1.2.3.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS36.300, clause 10.1.1.1 and 
TS 36.304, clause 4.1, 5.2.1, 5.2.3.2, 5.2.4.6 and 5.3.1. 

[TS 36.300, clause 10.1.1.1] 



Cell selection: 

- The UE NAS identifies a selected PLMN and equivalent PLMNs; 

The UE searches the E-UTRA frequency bands and for each carrier frequency identifies the strongest cell. It 
reads cell system information broadcast to identify its PLMN(s): 

The UE may search each carrier in turn ("initial cell selection") or make use of stored information to shorten 
the search ("stored information cell selection"). 

The UE seeks to identify a suitable cell; if it is not able to identify a suitable cell it seeks to identify an 
acceptable cell. When a suitable cell is found or if only an acceptable cell is found it camps on that cell and 
commence the cell reselection procedure: 

A suitable cell is one for which the measured cell attributes satisfy the cell selection criteria; the cell PLMN 
is the selected PLMN, registered or an equivalent PLMN; the cell is not barred or reserved and the cell is not 
part of a tracking area which is in the list of "forbidden tracking areas for roaming"; 

An acceptable cell is one for which the measured cell attributes satisfy the cell selection criteria and the cell 
is not barred; 



[TS 36.304, clause 4.1] 



With the cell selection, the UE searches for a suitable cell of the selected PLMN and chooses that cell to provide 
available services, further the UE shall tune to its control channel. This choosing is known as "camping on the cell". 

The UE will, if necessary, then register its presence, by means of a NAS registration procedure, in the tracking area of 
the chosen cell and as outcome of a successful Location Registration the selected PLMN becomes the registered PLMN 

[5]. 
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If the UE finds a more suitable cell, according to the cell reselection criteria, it reselects onto that cell and camps on it. 
If the new cell does not belong to at least one tracking area to which the UE is registered, location registration is 
performed. 



[TS 36.304, clause 5.2.1] 



When camped on a cell, the UE shall regularly search for a better cell according to the cell reselection criteria. If a 
better cell is found, that cell is selected. 



[TS 36.304, clause 5.2.3.2] 

The cell selection criterion S is fulfilled when: 



Srxlev > 



Where: 



Srxlev = Qrxievmeas - (Qixlevmiti - Qrxlevminoffset) - Pcompensation 



Where: 

the signalled value QrxlevminOffset is only applied when a cell is evaluated for cell selection as a result of a periodic 
search for a higher priority PLMN while camped normally in a VPLMN [5]. During this periodic search for higher 
priority PLMN the UE may check the S criteria of a cell using parameter values stored from a different cell of this 
higher priority PLMN. 



Srxlev 


Cell Selection RX level value (dB) 


Urxlevmeas 


IVIeasured cell RX level value (RSRP). 


Qrxlevmin 


IVIinimum required RX level in the cell (dBm) 


Qrxlevminoffset 


Offset to the signalled Qrxlevmin taken into account in the Srxlev 
evaluation as a result of a periodic search for a higher priority PLIVIN 
while camped normally in a VPLIVIN [5] 


Pcompensation 


[FFS] 



[TS 36.304, clause 5.2.4.6] 

In all cases, the UE shall reselect the new cell, only if the following conditions are met: 

the new cell is better ranked than the serving cell during a time interval Treselections 
more than 1 second has elapsed since the UE camped on the current serving cell. 

[TS 36.304, clause 5.3.1] 

Cell status and cell reservations are indicated in the SystemlnformationBlockTypel by means of three Information 
Elements: 

cellBarred (IE type: "barred" or "not barred") 

In case of multiple PLMNs indicated in SIB 1 sharing, this IE is common for all PLMNs 
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When cell status is indicated as "not barred", "not reserved" for operator use and "not reserved" for future extension 
(Cell Reservation Extension), 

All UEs shall treat this cell as candidate during the cell selection and cell re-selection procedures. 



When cell status "barred" is indicated. 

The UE is not permitted to select/re-select this cell, not even for emergency calls. 

The UE shall ignore the "Cell Reserved for future extension (Cell Reservation Extension) use" IE. 

The UE shall select another cell 



6.1.2.3.3 
6.1.2.3.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 and Cell 2 

Cell 1 and Cell 2 are high quality cells on the same E-UTRA frequency and different tracking areas: 

Cell 1 serving cell, Srxlevceii i>0 
- Cell 2 Srxlevceii 2>0 

Treselection ceii i = Treselection ceii 2 > 1 second 

UE: 

None. 

Preamble: 

UE is in state Registered, Idle Mode (state 2) according to [18]. 



6.1.2.3.3.2 



Test procedure sequence 



Table 6.1.2.3.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl" 
and "T2" are to be applied subsequently. The exact instants on which these values shall be applied are described in the 
texts in this clause. 

Table 6.1.2.3.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Celll 


Cell 2 


Remark 


TO 


Cell-specific RS EPRE 


dBm 


60 


80 


Srxlevceii 1 > Srxlevceii 2 > Srxlevceii 4, such that 
camping on Cell 1 is guaranteed 


Qrxlevmin 


dBm 


-110 


-110 




Qrxlevminoffset 


dB 










Qhyst 


dB 










Treselection 


s 


7 


7 


Cell reselection timer values for EUTRA cells 


Srxlev* 


dB 


50 


30 


Cell 1 is the strongest cell 


Tl 


Cell-specific RS EPRE 


dBm 


120 


80 


Srxlevceii 1 < 


Srxlev* 


dB 


-10 


30 


Cell 2 becomes the strongest cell 


T2 


Cell-specific RS EPRE 


dBm 


-100 


-80 


Srxlevceii 2 > Srxlevceii 1 > 


Srxlev* 


dB 


10 


30 


Cell 1 becomes suitable 


cellBarred 


- 


notBarred 


barred 


Serving cell becomes barred 
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Table 6.1.2.3.3.2-2: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


SS re-adjusts the cell-specific reference signal 
level of Cell 1 according to row "11" in table 
6.1.2.3.3.2-1. 










2 


Check: Is there any random access requests 
from the UE on Cell 2 within the next [5s]? 


- 


- 


1 


P 


3 


SS changes serving cell signal level and SIB1 
IE ce//6arrec/ according to row "T2" in table 
6.1 .2.3.3.2-1 and transmits a Paging message 
including systemlnfoModification 


<— 


Paging 






4 


Check: Is there any random access request 
from the UE on Cell 1? 


- 


- 


2 


P 



6.1 .2.3.3.3 Specific message or IE contents 

Table 6.1.2.3.3.3-1 Conditions for tables 6.1.2.3.3.3-2, 6.1.2.3.3.3-3 and 6.1.2.3.3.3-4 





Condition 


descriptions 


Cein 

This condition applies to system information transmitted on Cell 1 . 


Cell 2 

This condition applies 


to system information transmitted on Cell 2. 



Table 6.1.2.3.3.3-2 SystemlnformationBlockTypel for cells 1 and 2 (preamble and all steps, Table 

6.1.2.3.3.2-1) 



Derivation Path: 36.508 clause 4.4.3.2 


Information Element 


Value/remarl( 


Comment 


Condition 


SystemlnformationBlockTypel ::= SEQUENCE { 








cellAccessRelatedlnformation SEQUENCE { 








trackingAreaCode 


FFS 


different for all 
cells 


CelM 
Cell 2 


cell Identity 


FFS 


different for all 
cells 




cellBarred 


See table 6.1.2.3.3.2-1 




Cell 1 
Cell 2 


} 








cellSelectionlnfo SEQUENCE { 








q-Rxlevmin 


-55(-110dBm) 






q-Rxlevminoffset 


Not present 






} 








schedullnglnformation ::= SEQUENCE (SIZE 
(1 ..maxSI-Message)) OF SEQUENCE {} 


Combination 1 in TS 
36.508 section 4.4.3.1.1 


Only SIB2 and 
SIB3 are 
transmitted 


Cell 1 
Cell 2 


} 









Table 6.1.2.3.3.3-3 SystemlnformationBlockTypeS for cells 1 and 2 preamble and all steps, table 

6.1.2.3.3.2-1 



Derivation Path: 36.508 clause 4.4.3.3, Table 4.4.3.3-2 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockType3 ::= SEQUENCE { 








cellReselectionlnfoCommon SEQUENCE { 








q-Hyst 


dBO 






t-ReselectionEUTRAN 


7 




Cell 1 




7 




Cell 2 


1 








} 
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6.1.2.4 Cell reselection 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41 and 36.304 v8.3.0 i.e. after RAN#41. 



6.1.2.4.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE detects the cell ranked as the best cell 
then { UE reselects the new cell } 



6.1.2.4.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.304, clause 5.2.4.2 and 
5.2.4.6. 

[TS 36.304, clause 5.2.4.2] 

Following rules are used by the UE to limit needed measurements: 

- If SseivingCeii > Sintiaseaich. UE may choose to uot perform intra-frequency measurements. 

- If SservingCeii <= Sintrasearch. UE shall perform intra-frequeucy measurements. 

The UE shall apply the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are 
indicated in system information and for which the UE has priority provided as defined in 5.2.4.1: 

o For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than the 

reselection priority of the current E-UTRA frequency the UE shall perform measurements of higher priority 
E-UTRAN inter-frequencor inter-RAT frequencies according to [10]. 

o For an E-UTRAN inter-frequency with a equal or lower reselection priority than the reselection priority of 
the current E-UTRA frequency and for inter-RAT frequency with lower reselection priority than the 
reselection priority of the current E-UTRAN frequency: 

■ If SseivingCeii > Snonintrasearch UE may choosc uot to perform measurcmcuts of E-UTRAN inter-frequencies or 
inter-RAT frequencies of equal or lower priority. 



11 SseivingCell <— Sn 



'nonintraseaich the UE shall perform measurements of E-UTRAN inter-frequencies or inter- 
RAT frequencies cells of equal or lower priority according to [10]. 



Where SseivingCeii is the Srxlev-value of the serving cell. 

[TS 36.304, clause 5.2.4.6] 

The cell-ranking criterion Rs for serving cell and Rn for neighbouring cells is defined by: 



Rs = Qmeas,s + Qhystj 

Rn=Qmeas,n- Qoffsct 



where: 



Q. 



Qoffset 



RSRP measurement quantity used in cell reselections. 



For intra-frequency: Equals to Qoffsets,n, if Qoffsets,n is valid, 
otherwise this equals to zero. 

For inter-frequency: Equals to Qoffsets.n plus Qoffsetfrequency, if 
Qoffsets.n is valid, otherwise this equals to Qoffsetfrequency. 



The UE shall perform ranking of all cells that fulfill the cell selection criterion S, which is defined in 5.2. 1 .2 
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The cells shall be ranked according to the R criteria specified above, deriving Qmeas.n and Qmeas.s and calculating the R 
values using averaged RSRP results. 

If a cell is ranked as the best cell the UE shall perform cell re-selection to that cell. If this cell is found to be non- 
suitable, the UE shall behave according to subclause 5.2.4.4. 

In all cases, the UE shall reselect the new cell, only if the following conditions are met: 

the new cell is better ranked than the serving cell during a time interval Treselections 

more than 1 second has elapsed since the UE camped on the current serving cell. 



6.1.2.4.3 
6.1.2.4.3.1 



Test description 
Pre-test conditions 



System Simulator: 

Cell 1, Cell 2 and Cell 4 are high quality cells on the same E-UTRA frequency: 
Cell 1 serving cell, Srxlevceii i>0 (FFS Qrxievmeas, Qrxlevmin) 

- Cell 2 Srxlevceii 2>0 (FFS Qrxievmeas, Qrxlcvmin) 

- Cell 4 Srxlevceii 4>0 (FFS Qixievmeas, Qrxlevmin) 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) on Cell 1 according to [18]. 



6.1.2.4.3.2 



Test procedure sequence 



Table 6.1.2.4.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 6.1.2.4.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Celll 


Cell 2 


Cell 4 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P03 (FFS) 


Shall be assigned values to satisfy Srxlevceii i 
> Srxlevceii2 > Srxlevceiu, such that camping 
on Cell 1 is guaranteed 


Tl 


Ro 


dBm 


P11 (FFS) 


P02 (FFS) 


P03 (FFS) 


Power P1 1 shall be assigned values to 
satisfy Rceii i < Rceii 2- 



Table 6.1.2.4.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS changes Cell 1 level according to the 
row "Tl" in table 6.1.2.4.3.2-1. 


- 


- 


- 


- 


2 


Wait for [5s] for the UE to perform cell 
reselection procedure. 


- 


- 


- 


- 


3 


Check: Is there any random access requests 
from the UE on Cell 2? 


- 


- 


1 


P 
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6.1 .2.4.3.3 Specific message contents 

Table 6.1.2.4.3.3-1: Systemlnformation BlockTypeS ior CeW 1 (pre-test conditions) 



Derivation path: 36.508 table 4.4.3.3-2 | 


Information Element 


Value/Remarl< 


Comment 


Condition 


SystemlnformationBlocl<Type3 ::= SEQUENCE { 
cellReselectionlnfoCommon SEQUENCE { 

q-Hyst 
} 

}'" 


clBO 







6.1 .2.5 Cell reselection for inter-band operation 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41 and 36.304 v8.3.0 i.e. after RAN#41. 



6.1.2.5.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE detects the cell re- selection criteria are met for the cell on the different frequency 
band } 

then { UE reselects the new cell } 



6.1.2.5.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.304, clause 5.2.4.1, 
5.2.4.2 and 5.2.4.5. 

[TS 36.304, clause 5.2.4.1] 

Absolute priorities of different E-UTRAN frequencies or inter-RAT frequencies may be provided to the UE in the 
system information or in the RRC message releasing the RRC connection. If priorities are assigned via dedicated 
signalling, the UE shall ignore all the priorities provided in system information. The UE shall delete priorities provided 
by dedicated signalling when: 

- the UE enters RRC_CONNECTED state; or 

the optional validity time of dedicated priorities (T320) expires; or 

a PLMN selection is performed on request by NAS [5]. 

NOTE: Equal priorities between RATs are not supported. 

UE shall only perform reselection evaluation for E-UTRAN frequencies and inter-RAT frequencies that are given in 
system information and for which the UE has a priority provided. 

[TS 36.304, clause 5.2.4.2] 

Following rules are used by the UE to limit needed measurements: 

- If SseivingCeii > Sintraseaich. UE may choosc to uot perform intra-frequency measurements. 

If SseivingCeii <= S intrasearch, UE shall perform intra-frequeucy measurements. 

The UE shall apply the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are 
indicated in system information and for which the UE has priority provided as defined in 5.2.4. 1 : 

o For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than the 

reselection priority of the current E-UTRA frequency the UE shall perform measurements of higher priority 
E-UTRAN inter-frequencor inter-RAT frequencies according to [10]. 
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o For an E-UTRAN inter-frequency with a equal or lower reselection priority than the reselection priority of 
the current E-UTRA frequency and for inter-RAT frequency with lower reselection priority than the 
reselection priority of the current E-UTRAN frequency: 

■ If SservingCeii > Snonintrasearch UE may choosc not to perform mcasuremcnts of E-UTRAN inter-frequencies or 
inter-RAT frequencies of equal or lower priority. 

■ If SservingCeii <= Snonintrasearch the UE shall perform mcasurements of E-UTRAN inter-frequencies or inter- 
RAT frequencies cells of equal or lower priority according to [10]. 

Where SservingCeii is the Srxlev- value of the serving cell. 

[TS 36.304, clause 5.2.4.5] 

Criteria 1 : the SnonServingCeii.x of a cell on evaluated frequency is greater than Thresh^^ high during a time interval 
TreselectionRAx; 

Cell reselection to a cell on a higher priority E-UTRAN frequency or inter-RAT frequency than serving frequency shall 
be performed if: 

A cell of a higher priority E-UTRAN frequency or inter-RAT frequency fulfills criteria 1 ; and 

more than 1 second has elapsed since the UE camped on the current serving cell. 

Cell reselection to a cell on a lower priority E-UTRAN frequency or inter-RAT frequency than serving frequency shall 
be performed if: 

No cell on serving frequency or on a higher priority E-UTRAN frequency or inter-RAT frequency than serving 
frequency fulfills the criteria 1 ; and 

SservingCeii < ThrcshSeiving, low ^nd the SnonServingCeii.x of ^ ccll of a lowcr priority E-UTRAN frequency or inter-RAT 
frequency is greater than Thresh^, low during a time interval TreselectionRAx; and 

more than 1 second has elapsed since the UE camped on the current serving cell. 

Cell reselection to a cell on an equal priority E-UTRAN frequency shall be based on ranking for Intra-frequency Cell 
Reselection as defined in sub-clause 5.2.4.6. 

SnonServingCeii.x IS the Srxlcv-valuc of a cvaluatcd cell. In all the above criteria the value of TreselectionRAx is scaled when 
the UE is in the medium or high mobility state as defined in subclause 5.2.4.6. If more than one cell meets the above 
criteria, the UE shall reselect a cell ranked as the best cell among the cells meeting the criteria on the highest priority 
RAT or the highest priority frequency if the highest priority RAT is E-UTRA. 

Note: It is FFS what the definition is for SnonServingCell,x for cdma2000 RATs. 

6.1.2.5.3 Test description 

6.1.2.5.3.1 Pre-test conditions 

System Simulator: 

- Cell 1, Cell 3 and Cell 10 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) on Cell 1 according to [18]. 
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6.1.2.5.3.2 



Test procedure sequence 



Table 6.1.2.5.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 6.1.2.5.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


CelM 


Cell 3 


Cell 10 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P03 (FFS) 


Shall be assigned values to satisfy Srxlevceii i 
> Srxlevceii 3 > Srxlevceii 10, such that camping 
on Cell 1 is guaranteed 


Tl 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P13(FFS) 


Cell 3 and Cell 10 becomes stronger than 
Threshx, hiqh 



Table 6.1.2.5.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS changes Cell 1 , Cell 3 and Cell 1 
level according to the row "11" in table 
6.1.2.5.3.2-1. 










2 


Wait for [5 s] for the UE to perform cell 
reselection procedure. 


- 


- 


- 


- 


3 


Check; Is there any random access requests 
from the UE on Cell 10? 


- 


- 


1 


P 



6.1 .2.5.3.3 Specific message contents 

Table 6.1.2.5.3.3-1: Systemlnformation BlockTypeS ior CeW 1 (pre-test conditions) 



Derivation path: 36.508 table 4.4.3.3-2 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType3 ::= SEQUENCE { 
cellReselectionServingFreqInfo SEQUENCE { 

cellReselectionPriority 
} 


1 







Table 6.1.2.5.3.3-2: SystemlnformationBlockTypeS ior CeW 1 (pre-test conditions) 



Derivation path: 36.508 table 4.4.3.3-4 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlocklypeS ::= SEQUENCE { 
interFreqCarrierFreqList SEQUENCE { 
eutra-CarrierFreq[1] SEQUENCE { 
earfcn-DL 

} 

cellReselectionPriority[1 ] 
eutra-CarrierFreq[2] SEQUENCE { 
earfcn-DL 

} 

cell Reselection Priority[2] 

} 

} 


2 entries 

Same downlink EARFCN 
as used for Cell 3 

3 

Same downlink EARFCN 
as used for Cell 10 

5 







£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 26 ETSI TS 136 523-1 V8.0.1 (2009-01) 

6.1 .2.6 Cell reselection using Qhyst, Qoffset and Treselection 

6.1.2.6.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_IDLE state, and the UE is not in high mobility state } 
ensure that { 

when { Qhyst is non-zero in system information } 

then { UE reselects the highest ranked cell taking this Qhyst value into account} 



(2) 

with { UE in E-UTRA RRC_IDLE state, and the UE is not in high mobility state } 
ensure that { 

when { cell reselection criteria are fulfilled during a time interval Treselection } 
then { UE reselects the highest ranked cell } 
} 

(3) 

with { UE in E-UTRA RRC_IDLE state, and the UE is not in high mobility state } 
ensure that { 

when { Qoffset is non-zero in system information } 

then { UE reselects the highest ranked cell taking this Qoffset value into account } 
} 

6.1.2.6.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS36.300, clause 10.1.1.2 and 
TS 36.304, clauses 5.2.1 and 5.2.4.6 and TS 36.331 clause 6.3.1. 

[TS 36.300, clause 10.1.1.2] 

UE in RRC_IDLE performs cell reselection. The principles of the procedure are the following: 

The UE makes measurements of attributes of the serving and neighbour cells to enable the reselection process: 

There is no need to indicate neighbouring cell in the serving cell system information to enable the UE to 
search and measure a cell i.e. E-UTRAN relies on the UE to detect the neighbouring cells; 

For the search and measurement of inter-frequency neighbouring cells, only the carrier frequencies need to be 
indicated; 

Measurements may be omitted if the serving cell attribute fulfils particular search or measurement criteria. 

Cell reselection identifies the cell that the UE should camp on. It is based on cell reselection criteria which 
involves measurements of the serving and neighbour cells: 

Intra-frequency reselection is based on ranking of cells; 



Cell reselection parameters are applicable for all UEs in a cell. 



[TS 36.304, clause 5.2.1] 



When camped on a cell, the UE shall regularly search for a better cell according to the cell reselection criteria. If a 
better cell is found, that cell is selected. 



[TS 36.304, clause 5.2.4.6] 
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The cell-ranking criterion R^ for serving cell and R,, for neighbouring cells is defined by: 



where: 



Qrr 



Qoffset 



Rs = Qmeas,s + Qhysts 

Rn=Qmeas,n- Qoffset 



RSRP measurement quantity used in cell reselections. 



Equals to Qoffsets.n if it is valid otherwise this equals to 
Qoffsetfrequency 



The UE shall perform ranking of all cells that fulfill the cell selection criterion S, which is defined in 5.2. 1 .2 

RAN5 Editor's note: This reference (5.2.1.2) in 36.304 is incorrect and should be replaced with 5.2.3.2. 

The cells shall be ranked according to the R criteria specified above, deriving Qmeas.n and Qmeas.s and calculating the R 
values using averaged RSRP results. 

If a cell is ranked as the best cell the UE shall perform cell re-selection to that cell. 



In all cases, the UE shall reselect the new cell, only if the following conditions are met: 

the new cell is better ranked than the serving cell during a time interval TreselectioUs 

more than 1 second has elapsed since the UE camped on the current serving cell. 
Note: There may need to have additional measurement quantities in criterion R. 
Note: Scaling of measurement rule parameters need to be specified when parameters are finalized. 
Note: Exact scaling parameters for different mobility states are FES. 
[TS 36.331, clause 6.3.1] 



The IE SystemInfonnationBlockType4 contains information about the serving neighbouring frequencyies and intra- 
frequency neighbouring cells relevant for cell re-selection, covering both E-UTRA and other RATs. The IE includes 
cell re-selection parameters common for a frequency as well as cell specific re-selection parameters. 



6.1.2.6.3 
6.1.2.6.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1 and Cell 2 

Cell 1 and Cell 2 are high quality cells on the same E-UTRA frequency and different tracking areas: 

- Cell 1 serving cell, Srxlevceii i>0, (FFS Q,xievmeas. Qrxlevmin) 

Cell 2 intra-frequency cell Srxlevceii 2>0, (FFS Qrxievmeas, Qrxlevmin) 

All cells broadcast system information. Serving cell does not continuously page UE. Normal response to 
RRCConnectionRequest so Attach can be done 



ETSI 



3GPP TS 36.523-1 version 8.0.1 Release 8 



28 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



UE: 

None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 



6.1.2.6.3.2 



Test procedure sequence 



Table 6.1.2.6.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Rows marked "TO" denote the initial conditions, while rows marked "Tl", 
"T2", "T3", "T4", "T5", "T6" and "T7" are to be applied subsequently. The exact instants on which these values shall 
be applied are described in the texts in this clause. 

Table 6.1.2.6.3.2-1 : Time instances of cell power level and parameter change 



Tl 


Parameter 


Unit 


CelM 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


Shall be assigned values to ensure 
Srxlevceii i > Srxlevceii 2 such that 
camping on Cell 1 is guaranteed 


Tracking Area Code 


- 


TAC1 (FFS) 


TAC2 (FFS) 




Qhyst 


dB 


5^0 (FFS) 







Qoffset 


dB 










Treselection 


s 










Tl 


Ro 


dBm 


P02 (FFS) 


P01 (FFS) 


Cell 2 becomes stronger than Cell 1 
but Cell 1 remains the highest ranked 
one due to QhystsCein 


T2 


Qhyst 


dB 








Qhystscein change causes Cell 2 to 
become highest ranked cell 


T3 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


Cell 1 becomes the strongest 


Qoffset 


dB 


?'0 (FFS) 





Cell 1 becomes the highest ranked 


T4 


Ro 


dBm 


P02 (FFS) 


P01 (FFS) 


Cell 1 becomes weaker but it remains 
the highest ranked one due to 

Qoffsets.nCell 1 


T5 


Qoffset 


dB 








Cell 2 becomes the highest ranked 
one due to Qoffsets.ncein change 


T6 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


Cell 1 becomes the highest ranked 
one 


Treselection 


s 


7 







T7 


Ro 


dBm 


P02 (FFS) 


P01 (FFS) 


Cell 2 becomes the highest ranked 
cell 
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Table 6.1.2.6.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS re-adjusts re-adjusts the cell-specific 
reference signal levels according to row "11 " in 
table 6.1.2.6.3.2-1. 










2 


Check: Wait to see if there is any random 
access request from the UE on Cell 2? 


- 


- 


1 


F 


3 


SS resets QhystsCein according to row "12" in 
table 6.1 .2.6.3.2-1 . and notifies UE of the 
system information change. 


<— 


Paging 






4 


Check: Wait to see if there is any random 
access request from the UE on Cell 2? 


- 


- 


1 


P 


5 


SS changes Qoffsets.nCein and re-adjusts 
cell-specific reference signal levels according 
to rows "13" in table 6.1 .2.6.3.2-1 . 










6 


Wait until there is any random access requests 
from the UE on Cell 1 


- 


- 


- 


- 


7 


SS re-adjusts cell-specific reference signal 
levels according to row "14" in table 
6.1.2.6.3.2-1. 










8 


Check: Wait to see if there is any random 
access requests from the UE on Cell 2? 


- 


- 


3 


F 


9 


SS resets Qoffsets.ncein according to row "15" 
in table 6.1 .2.6.3.2-1 and notifies UE of the 
system information change. 


<— 


Paging 






10 


Check: Wait to see if there is any random 
access request from the UE on Cell 2? 


- 


- 


3 


P 


11 


SS changes Treselection ceii i and re-adjusts 
cell-specific reference signal levels according 
to rows "16" in table 6.1 .2.6.3.2-1 . 










12 


Wait until there is any random access requests 
from the UE on Cell 1 


- 


- 


- 


- 


13 


SS re-adjusts cell-specific reference signal 
levels according to rows "17" in table 
6.1 .2.6.3.2-1 and waits TevaluateFDD, intra s 
(TS 36.133 clause 4.2.2.3) for FDD and TBD 
for TDD. 










14 


Check: Is there any random access requests 
from the UE on Cell 2 within the next 5 s? 


- 


- 


2 


F 


15 


Check: Is there any random access requests 
from the UE on Cell 2 within the next 7 s? 


- 


- 


2 


P 



Editor's note: The wait time in steps 2, 6, 8 and 12 has to cover the cell reselection delay according to TS 36.133 
plus the required tolerance to allow the UE to perform cell reselection (FFS). 

Editor's note: The wait time in steps 4 and 10 is required to allow UE enough time to read serving cell system 
information and perform cell reselection (FFS). 

Editor's note: The time interval in step 14 is set by Treselection ceii i - 2 s tolerance. The time interval in step 15 is 
set by 2 s tolerance + 1280 ms for DRX cycle + 1280 ms for system information block type scheduling + 
2 s tolerance. 

6.1 .2.6.3.3 Specific message contents 

Table 6.1.2.6.3.3-1 Conditions for tables 6.1.2.6.3.3-2 and 6.1.2.6.3.3-3 





Condition 


descriptions 


CelM 

This condition applies 


to system information transmitted on Cell 1 . 


Cell 2 

This condition applies 


to system information transmitted on Cell 2. 
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Table 6.1.2.6.3.3-2 SystemlnformationBlockType3 ior cells 1 and 2 (preamble and table 6.1.2.6.3.2-2; 



Derivation Path: 36.508 clause 4.4.3.3 | 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlocklypeS ::= SEQUENCE { 








cellReselectionlnfoCommon SEQUENCE { 








q-Hyst 


See table 6.1.2.6.3.2-1. 




Cell! 
Cell 2 


t-Reselection 


See table 6.1.2.6.3.2-1 




Cell 1 
Cell 2 










} 
















} 









Table 6.1.2.6.3.3-3 SystemlnformationBlockType4 ior cell 1 and 2 (preamble and table 6.1.2.6.3.2-2) 



Derivation Path: 36.508 clause 4.4.3.3 | 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockType4 ::= SEQUENCE { 








intraFreqNeighbouringCellList SEQUENCE (SIZE 
(1 ..maxCelllntra)) OF SEQUENCE {} 








physicalCellldentity [1] 


Physical cell identity of 

Cell 2 

Physical cell identity of 

CelM 




Cell 1 
Cell 2 


q-QffsetCell [1] 


See table 6.1.2.6.3.2-1. 




Colli 
Cell 2 


} 
















} 









6.1 .2.15 Inter-frequency cell reselection according to cell reselection priority provided 
bySIBs 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41 and 36.304 v8.3.0 i.e. after RAN#41. 



6.1.2.15.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE detects the cell re-selection criteria are met for the cell which belongs to the equal 
priority frequency } 

then { UE reselects the cell which belongs to the equal priority frequency } 

} 

(2) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE detects the cell re- selection criteria are met for the cell which belongs to the higher 
priority frequency } 

then { UE reselects the cell which belongs to the higher priority frequency } 
} 

(3) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE detects the cell re- selection criteria are met for the cell which belongs to the lower 
priority frequency } 

then { UE reselects the cell which belongs to the lower priority frequency } 
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6.1.2.15.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.304, clause 5.2.4.1, 
5.2.4.2, 5.2.4.5 and 5.2.4.6. 

[TS 36.304, clause 5.2.4.1] 

Absolute priorities of different E-UTRAN frequencies or inter-RAT frequencies may be provided to the UE in the 
system information or in the RRC message releasing the RRC connection. If priorities are assigned via dedicated 
signalling, the UE shall ignore all the priorities provided in system information. The UE shall delete priorities provided 
by dedicated signalling when: 

- the UE enters RRC_CONNECTED state; or 

the optional validity time of dedicated priorities (T320) expires; or 

a PLMN selection is performed on request by NAS [5]. 

NOTE: Equal priorities between RATs are not supported. 

UE shall only perform reselection evaluation for E-UTRAN frequencies and inter-RAT frequencies that are given in 
system information and for which the UE has a priority provided. 

[TS 36.304, clause 5.2.4.2] 

Following rules are used by the UE to limit needed measurements: 

If SservingCeii > Sintrasearch, UE may choosc to not perform intra-frequency measurements. 

If SservingCeii <= S intrasearch, UE shall perform intra-frcquency measurements. 

The UE shall apply the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are 
indicated in system information and for which the UE has priority provided as defined in 5.2.4. 1 : 

o For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than the 

reselection priority of the current E-UTRA frequency the UE shall perform measurements of higher priority 
E-UTRAN inter-frequencor inter-RAT frequencies according to [10]. 

o For an E-UTRAN inter-frequency with a equal or lower reselection priority than the reselection priority of 
the current E-UTRA frequency and for inter-RAT frequency with lower reselection priority than the 
reselection priority of the current E-UTRAN frequency: 

■ If SservingCeii > Snonintrasearch UE may choosc not to perform measurements of E-UTRAN inter-frequencies or 
inter-RAT frequencies of equal or lower priority. 

■ If SservingCeii <= Snonintrasearch the UE shall perform mcasurcmcnts of E-UTRAN inter-frequencies or inter- 
RAT frequencies cells of equal or lower priority according to [10]. 

Where SservingCeii is the Srxlev- value of the serving cell. 

[TS 36.304, clause 5.2.4.5] 

Criteria 1 : the SnonServingCeii.x of a cell on evaluated frequency is greater than Thresh^^ high during a time interval 
TreselectionRAx; 

Cell reselection to a cell on a higher priority E-UTRAN frequency or inter-RAT frequency than serving frequency shall 
be performed if: 

A cell of a higher priority E-UTRAN frequency or inter-RAT frequency fulfills criteria 1 ; and 

more than 1 second has elapsed since the UE camped on the current serving cell. 

Cell reselection to a cell on a lower priority E-UTRAN frequency or inter-RAT frequency than serving frequency shall 
be performed if: 

No cell on serving frequency or on a higher priority E-UTRAN frequency or inter-RAT frequency than serving 
frequency fulfills the criteria 1 ; and 
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Sservingceii < ThrcshSeiving, low ^nd the SnonServingCeii.x of a ccll of a lowcr priority E-UTRAN frequency or inter-RAT 
frequency is greater than Thresh^, low during a time interval TreselectionRAxi and 

more than 1 second has elapsed since the UE camped on the current serving cell. 

Cell reselection to a cell on an equal priority E-UTRAN frequency shall be based on ranking for Intra-frequency Cell 
Reselection as defined in sub-clause 5.2.4.6. 

SnonServingCeii.x IS the Srxlcv-valuc of a cvaluatcd cell. In all the above criteria the value of TreselectionRAx is scaled when 
the UE is in the medium or high mobility state as defined in subclause 5.2.4.6. If more than one cell meets the above 
criteria, the UE shall reselect a cell ranked as the best cell among the cells meeting the criteria on the highest priority 
RAT or the highest priority frequency if the highest priority RAT is E-UTRA. 

Note: It is FES what the definition is for SnonServingCell,x for cdma2000 RATs. 

[TS 36.304, clause 5.2.4.6] 

The cell-ranking criterion Rs for serving cell and Rn for neighbouring cells is defined by: 



Rs = Qmeas,s + Qhystg 

Rn=Qmeas,n- Qoffset 



where: 



Qrr 



Qoffset 



RSRP measurement quantity used in cell reselections. 



For intra-frequency: Equals to Qoffsets,n, if Qoffsets,n is valid, 
otherwise this equals to zero. 

For inter-frequency: Equals to Qoffsets.n plus Qoffsetfrequency, if 
Qoffsets.n is valid, otherwise this equals to Qoffsetfrequency- 



The UE shall perform ranking of all cells that fulfill the cell selection criterion S, which is defined in 5.2.1.2 

The cells shall be ranked according to the R criteria specified above, deriving Qmeas.n and Qmeas.s and calculating the R 
values using averaged RSRP results. 

If a cell is ranked as the best cell the UE shall perform cell re-selection to that cell. If this cell is found to be non- 
suitable, the UE shall behave according to subclause 5.2.4.4. 

In all cases, the UE shall reselect the new cell, only if the following conditions are met: 

the new cell is better ranked than the serving cell during a time interval Treselectionj 

more than 1 second has elapsed since the UE camped on the current serving cell. 



6.1.2.15.3 
6.1.2.15.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1, Cell 3 and Cell 6 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) on Cell 1 according to [18]. 
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6.1.2.15.3.2 



Test procedure sequence 



Table 6. 1 .2. 15.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked 
"Tl", "T2" and "T3" are to be applied subsequently. The exact instants on which these values shall be applied are 
described in the texts in this clause. 

Table 6.1.2.15.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


CelM 


Cell 3 


Cell 6 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P03 (FFS) 


Shall be assigned values to satisfy Srxlevceii i 
> Srxlevceii 3 > Srxlevceii e and Srxlevceii e < 
Threshceii isuch that camping on Cell 1 is 
guaranteed 


Tl 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P03 (FFS) 


P1 1 and P1 2 shall be assigned values to 
satisfy Rceii 1 < Rceii 3. 


T2 


Ro 


dBm 


P21 (FFS) 


P22 (FFS) 


P23 (FFS) 


P21 , P22 and P23 shall be assigned to 
satisfy Srxlevceii 1 < and Srxlevceii e > 

Threshcell3,hiqh. 


T3 


Ro 


dBm 


P21 (FFS) 


P32 (FFS) 


P33 (FFS) 


P32 and P33 shall be assigned values to 
satisfy Srxlevceii e < Threshsemng, low and 
Srxlevceiis > Threshceii e, low, SrxlevceiiK 
Srxlevceii 3 



Table 6.1.2.15.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS changes Cell 1 and Cell 3 level 
according to the row "T1 " in table 6.1 .2.1 5.3.2- 

1. 










2 


Check: Is there any random access requests 
from the UE on Cell 3? 


- 


- 


1 


P 


3 


Wait for 5 s. 


- 


- 


- 


- 


4 


The SS changes Cell 1 , Cell 3 and Cell 6 level 
according to the row "T2" in table 6.1.2.15.3.2- 

1. 










5 


Check: Is there any random access requests 
from the UE on Cell 6? 


- 


- 


2 


P 


6 


Wait for 5s. 


- 


- 


- 


- 


7 


The SS changes Cell 3 and Cell 6 level 
according to the row "T3" in table 6.1.2.15.3.2- 
1. 










8 


Check: Is there any random access requests 
from the UE on Cell 3? 


- 


- 


3 


P 



6.1.2.15.3.3 



Specific message contents 



Table 6.1.2.15.3.3-1 : Conditions for specific message contents 
in tables 6.1.2.15.3.3-2 and 6.1.2.15.3.3-3 



Condition 


Explanation 


Cell 1 


This condition applies to system information transmitted on Cell 1 . 


Cell 3 


This condition applies to system information transmitted on Cell 3. 


Cell 1 1 


This condition applies to system information transmitted on Cell 6. 
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Table 6.1.2.15.3.3-2: SystemlnformationBlockTypeS ior Cell 1, Cell 3 and Cell 6 (preamble and all 

steps, Table 6.1.2.15.3.2-2) 



Derivation path: 36.508 table 4.4.S.3-2 | 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockTypeS ::= SEQUENCE { 
cellReselectionServingFreqInfo SEQUENCE { 
cellReselectionPriority 
} 

} 


5 




Cells 



Table 6.1.2.15.3.3-2: SystemlnformationBlockTypeS \or Cell 1, Cell 3 and Cell 6 (preamble and all 

steps, Table 6.1.2.15.3.2-2) 



Derivation path: 36.508 table 4.4.S.3-4 | 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType5 ::= SEQUENCE { 
interFreqCarrierFreqList SEQUENCE (SIZE 
(1 ..maxFreq)) OF SEQUENCE { 
eutra-CarrierFreq[1] SEQUENCE { 
earfcn-DL 


2 entries 
EARFCN of Cell 3 




CelM 




EARFCN of Cell 1 




Cells, 
Cells 


I 

eutra-CarrierFreq[2] SEQUENCE { 
earfcn-DL 


EARFCN of Cell 6 




CelM, 
Cells 


1 


EARFCN of Cell 3 




Cells 


} 
GellReselectionPriority[2] 

} 
} 


5 
4 




CelM, 
Cells 



Layer 2 



7.1 



MAC 



7.1.1 



Mapping between logical channels and transport channels 



7.1.1.1 



CCCH mapped to UL SCH/ DL-SCH / Reserved LCID (Logical Channel ID) 



Editors Note: This test case should be updated when description of disassembly and demultiplexing is added in 

36.5231 clause 5.3.3. Also, there is currently no core specification requirements matching with the first 
test purpose. 



7.1.1.1.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 

when { UE receives a MAC PDU on DL SCH and addressed to its T-CRNTI but including a reserved value 
for LCID } 

then { UE discards the MAC PDU } 
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(2) 

with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 
when { UE receives a MAC PDU on DL SCH and addressed to its T-CRNTI with value ' 00000 'B as LCID } 
then { UE forwards to upper layers the disassembled and demultiplexed SDU on logical channel 
CCCH } 



7.1.1.1.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 6.2.1 and 
5.3.3. 

[TS 36.321, clause 6.2.1] 

The MAC header is of variable size and consists of the following fields: 

LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or 
the type of the corresponding MAC control element or padding as described in tables 6.2.1-1 and 6.2. 1 -2 for the 
DL and UL-SCH respectively. There is one LCID field for each MAC SDU, MAC control element or padding 
included in the MAC PDU. The LCID field size is 5 bits; 



Table 6.2.1-1 Values of LCID for DL-SCH 



Index 


LCID values 


00000 


CCCH 


00001-01010 


Identity of tlie logical channel 


01011-11011 


Reserved 


11100 


UE Contention Resolution Identity 


11101 


Timing Advance 


11110 


DRX Command 


11111 


Padding 



[TS 36.321, clause 5.3.3] 

Editor's note: This section describes the disassembly and demultiplexing of MAC PDUs into MAC SDUs 

7.1.1.1.3 Test description 

7.1.1.1.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

UE: 
None. 

Preamble: 

- The UE is in state Registered, Idle mode (state 2) according to [18]. 
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7.1.1.1.3.2 



Test procedure sequence 



Table 7.1 .1 .1 .3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: Steps 1 to 4 shall be repeated 
for decreasing reserved LCID values from 
01011 to 11011. 










1 


The SS transmits a Paging message including 
a matched identity. 


- 


- 


1 


- 


2 


The UE transmits an RRCConnectionRequest 
message. 


- 


- 


1 


- 


3 


The SS Transmits a valid MAC PDU 
containing RRCConnectionSetup, and 
Contention Resolution Identity IVIAC Control 
Element except for LCID in IVIAC Header set to 
reserved value 11011 or lower (depending on 
iteration number). 


<— 


MAC PDU 


1 






EXCEPTION: In parallel with step 4, UE may 
execute parallel behaviour defined in table 
7.1.1.1.3.2-2 










4 


Check: For 5 seconds after Step3, does the 
UE transmit RRCConnectionSetupComplete 
message? 






1 


F 


5 


The SS transmits a Paging message including 
a matched identity. 


- 


- 


2 


- 


6 


The UE transmits an RRCConnectionRequest 
message. 


- 


- 


2 


- 


7 


The SS transmits a valid IVIAC PDU containing 
RRCConnectionSetup, and Contention 
Resolution Identity IVIAC Control Element and 
LCID in MAC Header set correctly to CCCH 
00000 


<— 


MAC PDU 


2 




8 


Check: does the UE transmit an 
RRCConnectionSetupComplete m essag e ? 


- 


- 


2 


P 



Table 7.1.1.1.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE transmits an RRCConnectionRequest 
message. 


- 


- 


- 


- 



7.1.1.1.3.3 
None. 



Specific message contents 



7.1 .1 .2 DTCH or DCCH mapped to UL SCH/ DL-SCH / Reserved LCID (Logical 

Channel ID) 



7.1.1.2.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_Connected state with DRB [Logical channel ID 3] established} 
ensure that { 

when { UE receives a MAC PDU on DL SCH and addressed to its CRNTI but including a reserved value 
for LCID } 

then { UE shall not forward the disassembled and demultiplexed SDU on the configured logical 
channels } 
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(2) 

with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 
when { UE receives a MAC PDU on DL SCH and addressed to its CRNTI with value ' 00011 'B as LCID } 
then { UE shall forward the disassembled and demultiplexed SDU on the corresponding logical 
channel } 

} 

Editors Note: This clause needs to be updated based on 36.321 clause 5.3.3 

7.1 .1 .2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 6.2.1 and 
5.3.3. 

[TS 36.321, clause 6.2.1] 

The MAC header is of variable size and consists of the following fields: 

LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or 
the type of the corresponding MAC control element or padding as described in tables 6.2.1-1 and 6.2.1-2 for the 
DL and UL-SCH respectively. There is one LCID field for each MAC SDU, MAC control element or padding 
included in the MAC PDU. The LCID field size is 5 bits; 



Table 6.2.1-1 Values of LCID for DL-SCH 



Index 


LCID values 


00000 


CCCH 


00001-01010 


Identity of tlie logical channel 


01011-11011 


Reserved 


11100 


UE Contention Resolution Identity 


11101 


Timing Advance 


11110 


DRX Command 


11111 


Padding 



[TS 36.321, clause 5.3.3] 

Editor's note: This section describes the disassembly and demultiplexing of MAC PDUs into MAC SDUs 

Test description 

Pre-test conditions 



7.1.1.2.3 




7.1.1.2.3.1 




System Simi 


lator 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
Note: In the following, the established DRB is assumed to have Logical channel ID 3 
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7.1.1.2.3.2 



Test procedure sequence 



Table 7.1.1.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 




EXCEPTION: the steps 1 and 2 are repeated 
for decreasing reserved LCID values from 
01011 to 11011 










1 


The SS transmits a valid IVIAC PDU containing 
a RLC PDU except for LCID in MAC Header 
set to reserved value 11011. 


<— 


MAC PDU 






2 


Check: does the UE transmit a Scheduling 
Request on PUCCH within 5 seconds after 
step 1 ? 


— > 


(SR) 


1 


F 


3 


The SS Transmits a valid IVIAC PDU 
containing RLC PDU with LCID in IVIAC 
Header set correctly to DRB 0001 1 . 


<— 


MAC PDU 






4 


Check: does the UE transmits a Scheduling 
Request on PUCCH? 


— > 


(SR) 


2 


P 


5 


The SS sends an UL grant suitable for the loop 
back PDU to transmitted 


<— 


(UL Grant) 


- 


- 


6 


Check: does the UE transmit a MAC PDU with 
LCID set to DRB 00011? 


-> 


MAC PDU 


2 


P 



7.1.1.2.3.3 
None. 



Specific message contents 



7.1.2 RACH 



Correct Selection of RACH parameters / Random Access Preamble and 
PRACH resource explicitly signalled to the UE by RRC [Non Contention 
Based Random Access Procedure] 

Test Purpose (TP) 



7.1.2.1 

7.1.2.1.1 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { SS sends an RRCConnectionReconf iguration message including RACH-ConfigDedicated information 
element} 

then { UE sends a prach preamble given in the RACH-ConfigDedicated on the target cell } 



7.1.2.1.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.1.2 and 
5.1.4. 

[TS 36.321, clause 5.1.2] 

The Random Access Resource procedure shall be performed as follows: 

If the Random Access Preamble and PRACH resource have been explicitly signalled: 

the UE can directly proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

[TS 36.321, clause 5.1.4] 
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Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the 
UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the TTI 
window RA_WINDOW_BEGIN — RA_WINDOW_END which starts at the subframe that contains the end of the 
preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes. The RA-RNTI 
associated with the PRACH resource in which the Random Access Preamble is transmitted, is computed as: 

RA-RNTI= t_id+10*f_id 

Where t_id is the index of the first subframe of the specified PRACH resource (0< t_id <10), and f_id is the index of the 
specified PRACH resource within that subframe, in ascending order of frequency domain (0< f_id< 6). The UE may 
stop monitoring for Random Access Response(s) after successful reception of a Random Access Response 
corresponding to the Random Access Preamble transmission. 

If a downlink assignment for this TTI has been received on the PDCCH for the RA-RNTI and the received TB is 
successfully decoded, the UE shall regardless of the possible occurrence of a measurement gap: 



if the Random Access Response contains a Random Access Preamble identifier corresponding to the 
transmitted Random Access Preamble (see subclause 5.1.3), the UE shall: 

consider this Random Access Response reception successful; 

- process the received Timing Alignment value (see subclause 5.2); 

- process the received UL grant value and indicate it to the lower layers; 

if the Random Access Preamble was explicitly signalled (i.e., not selected by MAC): 
consider the Random Access procedure successfully completed. 

7.1.2.1.3 Test description 

7.1.2.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2. 

UE: 
None. 

Preamble: 

UE is in state Generic RB Established (state 3) according to [18] in cell 1. 
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7.1.2.1.3.2 



Test procedure sequence 

Table 7.1.2.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2, including explicit Random 
Access Preamble. 










2 


Check: does the UE transmit Preamble on 
PRACH corresponding to ra-Preamblelndex\r\ 
step 1 ? 


— > 


(PRACH Preamble) 


1 


P 


3 


The SS transmits Random Access Response 
on cell 2, with RAPID corresponding to ra- 
Preamblelndex in step 1 


<— 


Random Access Response 






4 


Check: Does the UE sends on cell 2, a MAC 
PDU containing 
RRCConnectionReconfigurationComplete? 


— > 


MAC PDU 


1 


P 


5 


Check: does the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC CONNECTED state in cell 2? 











7.1 .2.1 .3.3 Specific message contents 

Table 7.1 .2.1 .3.3-1 : RRCConnectionReconfiguration (step 1 , table 7.1 .2.1 .3.2-1) 



Derivation Path: 36.508, Table 4.6.1-6, condition RBC-HO 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEQUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HO 






targetCellldentity 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






eutra-CarrierFreq 


Not present 






rach-ConfigDedicated SEQUENCE { 








ra-Preamblelndex 


Arbitrarily set to value not 






} 
} 
} 
} 
} 
} 


included in SI 







7.1.2.2 



7.1.2.2.1 



Correct Selection of RACH parameters / Random Access Preamble and 
PRACH resource explicitly signalled to the UE in PDCCH Order [Non 
Contention Based Random Access Procedure] 

Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { PDCCH control command is received providing Random Access Preamble 
then { UE sends a prach preamble given in the PDCCH Order } 
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(2) 

with { UE in E-UTRA RRC_CONNECTED state and transmitted PRACH Preamble, after reception of PDCCH 
order } 
ensure that { 

when { UE does not receive a matching Random Accees response in ra-ResponseWindowSize {hence 
considers RACK attempt as failed) and PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_iyiAX 

} 

then { UE retransmists the Preamble given in the PDCCH Order } 

} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state and transmitted PRACH Preamble, after reception of PDCCH 
order } 
ensure that { 

when { PREAMBLE_TRANSMISSION_COUNTER is not less than PREAMBLE_TRANS_iyiAX } 
then { UE does not transmit the Preamble given in the PDCCH Order } 
} 

7.1.2.2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.1.2 and 
5.1.24. 

[TS 36.321, clause 5.1.2] 

The Random Access Resource procedure shall be performed as follows: 

If the Random Access Preamble and PRACH resource have been explicitly: 

the UE can directly proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

[TS 36.321, clause 5.1.4] 

Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the 
UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the TTl 
window RA_WlNDOW_BEGlN — RA_WlNDOW_END which starts at the subframe that contains the end of the 
preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes. The RA-RNTI 
associated with the PRACH resource in which the Random Access Preamble is transmitted, is computed as: 

RA-RNTI= t_id+10*f_id 

Where t_id is the index of the first subframe of the specified PRACH resource (0< t_id <10), and f_id is the index of the 
specified PRACH resource within that subframe, in ascending order of frequency domain (0< f_id< 6). The UE may 
stop monitoring for Random Access Response(s) after successful reception of a Random Access Response 
corresponding to the Random Access Preamble transmission. 

If a downlink assignment for this TTI has been received on the PDCCH for the RA-RNTI and the received TB is 
successfully decoded, the UE shall regardless of the possible occurrence of a measurement gap: 



if the Random Access Response contains a Random Access Preamble identifier corresponding to the 
transmitted Random Access Preamble (see subclause 5.1.3), the UE shall: 

consider this Random Access Response reception successful; 

- process the received Timing Alignment value (see subclause 5.2); 

- process the received UL grant value and indicate it to the lower layers; 

if the Random Access Preamble was explicitly signalled (i.e., not selected by MAC): 
consider the Random Access procedure successfully completed. 



If no Random Access Response is received within the TTI window [RA_WINDOW_BEGIN— RA_WINDOW_END], 
or if all received Random Access Responses contain Random Access Preamble identifiers that do not match the 
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transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the UE 
shall: 

if the Random Access procedure was initiated by the MAC sublayer itself; or 

if the Random Access procedure was initiated by a PDCCH order and the 
PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1 ; 

if in this Random Access procedure: 

the Random Access Preamble was selected by MAC: 

based on the backoff parameter in the UE, select a random backoff time according to a uniform 
distribution between and the Backoff Parameter Value; 

delay the subsequent Random Access transmission by the backoff time; 

- proceed to the selection of a Random Access Resource (see subclause 5.1.2). 



7.1.2.2.3 


Test description 


7.1.2.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] in cell 1 
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7.1.2.2.3.2 



Test procedure sequence 



Table 7.1.2.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a PDCCH order providing 
Random Access Preamble. 


<— 


(PDCCH Order) 


- 


- 


2 


Checl<: does tlie UE transmit a preamble on 
PRACHusing the same preamble index as 
given in step 1? 


— > 


(PRACH Preamble) 


1 


P 


3 


Check: does the UE transmit a preamble on 
PRACH after ra-ResponseWindowSize using 
the same preamble index as given in step 1? 


— > 


(PRACH Preamble) 


2 


P 


4 


Check: does the UE transmit a preamble on 
PRACH after ra-ResponseWindowSize using 
the same preamble index as given in step 1? 


— > 


(PRACH Preamble) 


2 


P 


5 


Check: does the UE transmit a preamble on 
PRACH after ra-ResponseWindowSize using 
the same preamble index as given in step 1? 


— > 


(PRACH Preamble) 


2 


P 


6 


Check: does the UE transmit a RACH 
preamble within the next 5 seconds? 


— > 


(PRACH Preamble) 


3 


F 


7 


The SS transmits a PDCCH order providing 
Random Access Preamble. 


<— 


(PDCCH Order) 


- 


- 


8 


Check: does the UE transmit a preamble on 
PRACH after ra-ResponseWindowSize using 
the same preamble index as given in step 7? 


— > 


(PRACH Preamble) 


1 


P 


9 


The SS transmits Random Access Response 
with RAPID corresponding to Preamble in step 
8 


<— 


Random Access Response 






10 


Check: does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC CONNECTED state? 











7.1.2.2.3.3 



Specific message contents 



Table 7.1 .2.2.3.3-1 : SystemlnformationBlockType2 (all steps, table 7.1 .2.2.3.2-1) 



Derivation Path: 36.508 clause 4.4.3.3, Table Nr. 4.4.3.3.-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 
radioResourceConfigCommon SEQUENCE { 
rach-Configuration SEQUENCE { 

ra-Supervisionlnformation SEQUENCE { 
preambleTransMax 

} 
} 
} 
} 
} 


n3 


PREAMBLE TRA 
NS_MAX 





7.1 .2.3 Correct Selection of RACH parameters, selected by MAC itself [Contention 

Based Random Access Procedure] 

7.1.2.3.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { SS sends a Paging message to the UE } 

then { UE transmits a random access preamble using a preamble in one of the two groups of random 
access preambles indicated in SIB2 } 
} 
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(2) 

with { UE in E-UTRA RRC_IDLE state and have transmitted a RRCConnectionRequest message } 
ensure that { 

when { SS does not respond before contention resolution timer expiry } 

then { UE transmits a random access preamble using a preamble in the same group of random access 
preambles as used for the first transmission of the RRCConnectionRequest message } 
} 

(3) 

with { UE in E-UTRA RRC_IDLE state and Random access procedure initiated by MAC} 
ensure that { 

when { SS does not respond before contention resolution timer expiry after more than 
PREAMBLE_TRANS_MAX transmissions from UE } 

then { UE transmits a random access preamble using a preamble in the same group of random access 
preambles as used for the first transmission of the RRCConnectionRequest message } 
} 

7.1.2.3.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.1.2 and 
5.1.5. 

[TS 36.321, clause 5.1.2] 

The Random Access Resource procedure shall be performed as follows: 

If the Random Access Preamble and PRACH resource have been explicitly signalled: 



else the Random Access Preamble shall be selected by the UE as follows: 

If the uplink message containing the C-RNTl MAC control element or the uplink message including the 
CCCH SDU has not yet been transmitted, the UE shall: 

if Random Access Preambles group B exists and if the potential message size (data available for 
transmission plus MAC header and, where required, MAC control elements) is greater than 
MESSAGE_SlZE_GROUP_A and if the pathloss is less than PARTITION_PATHLOSS_THRESHOLD 
then: 

select the Random Access Preambles group B; 

else: 

select the Random Access Preambles group A. 

else, if the uplink message containing the C-RNTl MAC control element or the uplink message including the 
CCCH SDU is being retransmitted, the UE shall: 

select the same group of Random Access Preambles as was used for the preamble transmission attempt 
corresponding to the first transmission of the uplink message containing the C-RNTl MAC control 
element or the uplink message including the CCCH SDU. 

randomly select a Random Access Preamble within the selected group. The random function shall be such 
that each of the allowed selections can be chosen with equal probability; 

if more than one PRACH resources are available in the same subframe (TDD), randomly select one. The 
random function shall be such that each of the allowed selections can be chosen with equal probability; 

proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

[TS 36.321, clause 5.1.5] 

Contention Resolution is based on C-RNTl on PDCCH and UE Contention Resolution Identity on DL-SCH.. 

Once the uplink message containing the C-RNTI MAC control element or the uplink message including the CCCH 
SDU is transmitted, the UE shall: 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 45 ETSI TS 136 523-1 V8.0.1 (2009-01) 

start the Contention Resolution Timer; 

regardless of the possible occurrence of a measurement gap, monitor the PDCCH until the Contention 
Resolution Timer expires; 



if the Contention Resolution Timer expires: 

consider the Contention Resolution not successful, 
if the Contention Resolution is considered not successful the UE shall: 

if the Random Access procedure was initiated by the MAC sublayer itself; or 

if the Random Access procedure was initiated by a PDCCH order and the 
PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1 ; 

..." proceed to the selection of a Random Access Resource (see subclause 5.1.2). 

discard the Temporary C-RNTI. 

7.1.2.3.3 Test description 

7.1.2.3.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 (FDD or TDD). 

- System information set using parameters as specified in Table 7.1.2.3.3.3-1. 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 
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7.1.2.3.3.2 



Test procedure sequence 



Table 7.1.2.3.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a Paging message Including 
a matched identity. 


- 


- 


- 


- 


2 


Checl<: does the UE transmit preamble on 
PRACH using a preamble in one of the 2 
preamble groups defined in SIB2 
(numberOfRA-Preambles and sizeOfRA- 
PreamblesGroupA) ? 


— > 


PRACH Preamble 


1 


P 


3 


Check: does the UE transmit preamble on 
PRACH using a preamble in one of the 2 
preamble groups defined in SIB2 
(numberOfRA-Preambles and sizeOfRA- 
PreamblesGroupA) ? 


— > 


PRACH Preamble 


1 


P 


4 


Check; does the UE transmit preamble on 
PRACH using a preamble in one of the 2 
preamble groups defined in SIB2 
{numberOfRA-Preambles and sizeOfRA- 
PreamblesGroupA) ? 


— > 


PRACH Preamble 


1 


P 


5 


The SS transmits Random Access Response 
with RAPID corresponding to the transmitted 
Preamble in step 4, including T-CRNTI and not 
including Backoff Indicator sub header. 


<— 


Random Access Response 


2 




6 


The UE transmits an RRCConnectionRequest 
message. 


- 


- 


2 


- 


7 


Check: does the UE transmit preamble on 
PRACH using a preamble belonging to the 
same preamble group like the preamble 
transmitted in step 4?. 


— > 


PRACH Preamble 


2 


P 


8 


Check: does the UE continue to repeatedly 
transmit for 2s after step 2 a preamble 
belonging to the same preamble group like the 
preamble transmitted in step 4? 
Note: 2s is the value of T302. 


— > 


PRACH Preamble 


2,3 


P 



7.1 .2.3.3.3 Specific message contents 

Table 7.1.2.3.3.3-1 : SystemlnformationBlockType2 (all steps, table 7.1.2.3.3.2-1) 



Derivation path: 36.508 clause 4.4.3.3, Table 4.4.3.3.-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 
radioResourceConfigCommon SEQUENCE { 
rach-Configuration SEQUENCE { 
preamblelnformation SEQUENCE { 
sizeOfRA-PreamblesGroupA 

} 

ra-Supervisionlnformation SEQUENCE { 
preambleTransMax 

} 
} 
} 

ue-TimersAndConstants SEQUENCE{ 
t300 
} 
} 


Any allowed value less 
than 'numberOfRA- 
Preambles' 

n3 
ms2000 


PREAMBLE TRA 
NS_MAX 

T300 
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7.1 .2.4 Random Access Procedure: Successful 

7. 1 .2.4. 1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { The SS pages the UE with a matching identity } 

then { UE tranmits a random access preamble in the next available Random Access occasion } 
} 

(2) 

with { UE in E-UTRA RRC_IDLE state after transmission of a PRACH preamble } 
ensure that { 

when { SS does not answer with a matching Random Accees Response within ra-ResponseWindowSize } 
then { UE retransmits a PRACH preamble} 
} 

7.1.2.4.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.1.2, 5.1.3 & 
5.1.4. 

[TS 36.321, clause 5.1.2] 

The Random Access Resource procedure shall be performed as follows: 

If the Random Access Preamble and PRACH resource have been explicitly signalled: 

the UE can directly proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

else the Random Access Preamble shall be selected by the UE as follows: 

If the uplink message containing the C-RNTl MAC control element or the uplink message including the 
CCCH SDU has not yet been transmitted, the UE shall: 

if Random Access Preambles group B exists and if the potential message size (data available for 
transmission plus MAC header and, where required, MAC control elements) is greater than 
MESSAGE_SlZE_GROUP_A and if the pathloss is less than PARTITION_PATHLOSS_THRESHOLD 
then: 

select the Random Access Preambles group B; 

else: 

select the Random Access Preambles group A. 

else, if the uplink message containing the C-RNTI MAC control element or the uplink message including the 
CCCH SDU is being retransmitted, the UE shall: 

select the same group of Random Access Preambles as was used for the preamble transmission attempt 
corresponding to the first transmission of the uplink message containing the C-RNTl MAC control 
element or the uplink message including the CCCH SDU. 

randomly select a Random Access Preamble within the selected group. The random function shall be such 
that each of the allowed selections can be chosen with equal probability; 

if more than one PRACH resources are available in the same subframe (TDD), randomly select one. The 
random function shall be such that each of the allowed selections can be chosen with equal probability; 

proceed to the transmission of the Random Access Preamble (see subclause 5.1.3). 

[TS 36.321, clause 5.1.3] 

The random-access procedure shall be performed as follows: 
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- If PREAMBLE_TRANSMIS SION_COUNTER = PREAMBLE_TRANS_MAX + 1 : 

indicate a Random Access problem to upper layers. 

[- set the parameter PREAMBLE_RECEIVED_TARGET_POWER to 

PREAMBLE_INITIAL_RECEIVED_TARGET_POWER + (PREAMBLE_TRANSMISSION_COUNTER-l) * 
POWER_RAMP_STEP;] 

determine the next available Random Access occasion (a UE may take into account the possible occurrence of 
measurement gaps when determining the next available Random Access occasion); 

instruct the physical layer to transmit a preamble using the selected PRACH resource, corresponding RA-RNTI, 
preamble index and PREAMBLE_RECEIVED_TARGET_POWER. 

[TS 36.321, clause 5.1.4] 

Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the 
UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTI defined below, in the TTI 
window RA_WINDOW_BEGIN — RA_WINDOW_END which starts at the subframe that contains the end of the 
preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes The RA-RNTI 
associated with the PRACH resource in which the Random Access Preamble is transmitted, is computed as: 

RA-RNTI= t_idH-10*f_id 

Where t_id is the index of the first subframe of the specified PRACH resource (0< t_id <10), and f_id is the index of the 
specified PRACH resource within that subframe, in ascending order of frequency domain (0< f_id< 6). The UE may 
stop monitoring for Random Access Response(s) after successful reception of a Random Access Response 
corresponding to the Random Access Preamble transmission. 

If a downlink assignment for this TTI has been received on the PDCCH for the RA-RNTI and the received TB is 
successfully decoded, the UE shall regardless of the possible occurrence of a measurement gap: 

if the Random Access Response contains a Backoff Indicator sub header: 

set the backoff parameter value in the UE as indicated by the BI field of the Backoff Indicator sub header 
and Table 7.2-1. 

else, set the backoff parameter value in the UE to ms. 

if the Random Access Response contains a Random Access Preamble identifier corresponding to the 
transmitted Random Access Preamble (see subclause 5.1.3), the UE shall: 

consider this Random Access Response reception successful; 

- process the received Timing Alignment value (see subclause 5.2); 

- process the received UL grant value and indicate it to the lower layers; 

- if the Random Access Preamble was explicitly signalled (i.e., not selected by MAC): 

consider the Random Access procedure successfully completed. 

else, if the Random Access Preamble was selected by UE MAC: 

set the Temporary C-RNTI to the value received in the Random Access Response message no later 
than at the time of the first transmission corresponding to the UL grant provided in the Random 
Access Response message; 

if this is the first successfully received Random Access Response within this Random Access 
procedure: 

if the transmission is not being made for the CCCH logical channel, indicate to the Multiplexing 
and assembly entity to include a C-RNTI MAC control element in the subsequent uplink 
transmission; 

obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity and store it in the 
[Message3] buffer. 
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NOTE: When an uplink transmission is required, e.g., for contention resolution, the eNB should not provide a 
grant smaller than 80 bits in the Random Access Response. 

NOTE: If within a Random Access procedure, an uplink grant provided in the Random Access Response for the 
same group of Random Access Preambles has a different size than the first uplink grant allocated during 
that Random Access procedure, the UE behaviour is not defined. 

If no Random Access Response is received within the TTI window [RA_WINDOW_BEGIN— RA_WINDOW_END], 
or if all received Random Access Responses contain Random Access Preamble identifiers that do not match the 
transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the UE 
shall: 

if the Random Access procedure was initiated by the MAC sublayer itself; or 

if the Random Access procedure was initiated by a PDCCH order and the 
PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1 ; 



- proceed to the selection of a Random Access Resource (see subclause 5.1.2). 
Editor's note: Whether error conditions are specified is FFS. 

7.1.2.4.3 Test description 

7.1.2.4.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

System information are set according to table 7.1.2.4.3.3-1 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 
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7.1.2.4.3.2 



Test procedure sequence 



Table 7.1.2.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a Paging message including 
a matched identity. 


- 


- 


- 


- 




EXCEPTION: In parallel with steps 2 to 7, 
parallel behaviour defined in table 7.1 .2.4.3.2- 
3 










2 


Check: does the UE transmit a preamble on 
PRACH, in an even frame number X, subframe 
number 4(FDD)/3(TDD)? 


— > 


PRACH Preamble 


1 


P 


3 


Check: does the UE transmit a preamble on 
PRACH, in an even frame number X+2, 
subframe number 4{FDD)/3(TDD)? 


— > 


PRACH Preamble 


1,2 


P 


4 


Check: does the UE transmit a preamble on 
PRACH, in an even frame number X+4, 
subframe number 4(FDD)/3(TDD)? 


— > 


PRACH Preamble 


1,2 


P 


5 


The SS transmits a Random Access Response 
with not-matching RA-ld, including T-CRNTI 
and not including Backoff Indicator sub 
header. 


<— 


Random Access Response 






6 


Check: does the UE transmit a preamble on 
PRACH in an even frame number X+6, 
subframe number 4(FDD)/3(TDD)? 


— > 


PRACH Preamble 


1,2 


P 


7 


Wait for 2s. 

Note: the UE may transmit additional RACH 

preambles 


— > 


PRACH Preamble 






8 


The SS transmits a Paging message including 
a matched identity. 


- 




- 


- 


9 


Check: does the UE transmit a preamble on 
PRACH, in an even frame number, subframe 
number 4(FDD)/3{TDD)? 


— > 


PRACH Preamble 


1 


P 


10 


The SS transmits Random Access Response 
with RAPID corresponding to the transmitted 
Preamble in step 9, including T-CRNTI and not 
including Backoff Indicator sub header. 


<— 


Random Access Response 






11 


The UE transmits an RRCConnectionRequest 
message. 


- 


- 


- 


- 


12 


The SS Transmits a valid IVIAC PDU 
containing RRCConnectionSetup, and 
including 'UE Contention Resolution Identity' 
IVIAC control element with matching 
'Contention Resolution Identity' 


<— 


MAC PDU 






13 


The UE transmits an 
RRCConnectionSetupComplete message. 


- 


- 


- 


- 



Table 7.1.2.4.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE transmits an RRCConnectionRequest 
message. 


- 


- 


- 


- 
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7.1 .2.4.3.3 Specific message contents 

Table 7.1.2.4.3.3-1 : SystemlnformationBlockType2 (all steps, table 7.1.2.4.3.2-1) 



Derivation path: 36.508 table 4.4.3.3.-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 








radioResourceConfigCommon SEQUENCE { 








rach-Configuration SEQUENCE { 








ra-Supervisionlnformation SEQUENCE { 








preamblelranslVlax 


n3 


PREAMBLE TRA 




} 




NS_MAX 




} 

prach-Configuration SEQUENCE { 








prach-Configlnfo SEQUENCE { 








prach-Configurationlndex 


1 


As per table 5.7.1 - 
2 of 36.211, this 
results in PRACH 
preamble 
transmission start 
in even frame 
numbers and sub- 
frame number 4 


FDD 


prach-Configurationlndex 





As portable 5.7.1- 
4 of 36.211, this 
results in PRACH 
preamble 
transmission with 
frequency 
resource index=0; 
occurring in even 
radio frames; 
resource is 
located in first half 
frame and sub 
frame number 3 


TDD 


} 




Notel 




I 
} 
ue-TimersAndConstants SEQUENCE { 








1300 
} 
} 


ms2000 


T300 




Note 1 : 36.508, Table 4.4.3.2-3 specifies tdd-Configuration-> subframeAssignment as sal . 



7.1 .2.5 Random Access Procedure: MAC PDU containing Multiple RAR's 

7.1.2.5.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_IDLE state and transmitted PRACH preamble } 
ensure that { 

when { UE receives during TTI window [RA_WINDOW_BEGIN-RA_WINDOW_END] MAC PDU containing multiple 
RAR's but with none of the subheaders cotains a RAPID correseponding to the UE } 

then { UE tranmits a random access preamble in the next available Random Access occasion } 
} 

(2) 

with { UE in E-UTRA RRC_IDLE state and transmitted PRACH preamble } 
ensure that { 

when { UE receives during TTI window [RA_WINDOW_BEGIN-RA_WINDOW_END] MAC PDU containing multiple 
RAR's and one of the subheaders cotains a RAPID correseponding to the UE } 
then { UE transmits MAC PDU containing RRCConnectionRequest } 
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7.1.2.5.2 Conformance requirements 

References: The conformance requirements covered in tlie current TC are specified in: TS 36.321, clause 5.1.3 and 
5.1.4. 

[TS 36.321, clause 5.1.3] 

The random-access procedure shall be performed as follows: 

- If PREAMBLE_TRANSM1S S10N_C0UNTER = PREAMBLE_TRANS_MAX + 1 : 

indicate a Random Access problem to upper layers. 

[- set the parameter PREAMBLE_RECEIVED_TARGET_POWER to 

PREAMBLE_1N1T1AL_RECE1VED_TARGET_P0WER + (PREAMBLE_TRANSMISSION_COUNTER-l) * 
POWER_RAMP_STEP;] 

determine the next available Random Access occasion (a UE may take into account the possible occurrence of 
measurement gaps when determining the next available Random Access occasion); 

instruct the physical layer to transmit a preamble using the selected PRACH resource, corresponding RA-RNTl, 
preamble index and PREAMBLE_RECEIVED_TARGET_POWER. 

[TS 36.321, clause 5.1.4] 

Once the Random Access Preamble is transmitted and regardless of the possible occurrence of a measurement gap, the 
UE shall monitor the PDCCH for Random Access Response(s) identified by the RA-RNTl defined below, in the TTl 
window RA_WlNDOW_BEGlN — RA_WlNDOW_END which starts at the subframe that contains the end of the 
preamble transmission [7] plus three subframes and has length ra-ResponseWindowSize subframes. The RA-RNTI 
associated with the PRACH resource in which the Random Access Preamble is transmitted, is computed as: 

RA-RNTI= t_idH-10*f_id 

Where t_id is the index of the first subframe of the specified PRACH resource (0< t_id <10), and f_id is the index of the 
specified PRACH resource within that subframe, in ascending order of frequency domain (0< f_id< 6). The UE may 
stop monitoring for Random Access Response(s) after successful reception of a Random Access Response 
corresponding to the Random Access Preamble transmission. 

If a downlink assignment for this TTI has been received on the PDCCH for the RA-RNTI and the received TB is 
successfully decoded, the UE shall regardless of the possible occurrence of a measurement gap: 

if the Random Access Response contains a Backoff Indicator sub header: 

set the backoff parameter value in the UE as indicated by the BI field of the Backoff Indicator sub header 
and Table 7.2-1. 

else, set the backoff parameter value in the UE to ms. 

if the Random Access Response contains a Random Access Preamble identifier corresponding to the 
transmitted Random Access Preamble (see subclause 5.1.3), the UE shall: 

consider this Random Access Response reception successful; 

- process the received Timing Alignment value (see subclause 5.2); 

- process the received UL grant value and indicate it to the lower layers; 

- if the Random Access Preamble was explicitly signalled (i.e., not selected by MAC): 

consider the Random Access procedure successfully completed, 
else, if the Random Access Preamble was selected by UE MAC: 
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NOTE: 



NOTE: 



set the Temporary C-RNTI to the value received in the Random Access Response message no later 
than at the time of the first transmission corresponding to the UL grant provided in the Random 
Access Response message; 

if this is the first successfully received Random Access Response within this Random Access 
procedure: 

if the transmission is not being made for the CCCH logical channel, indicate to the Multiplexing 
and assembly entity to include a C-RNTI MAC control element in the subsequent uplink 
transmission; 

obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity and store it in the 
[Message3] buffer. 

When an uplink transmission is required, e.g., for contention resolution, the eNB should not provide a 
grant smaller than 80 bits in the Random Access Response. 

If within a Random Access procedure, an uplink grant provided in the Random Access Response for the 
same group of Random Access Preambles has a different size than the first uplink grant allocated during 
that Random Access procedure, the UE behaviour is not defined. 



If no Random Access Response is received within the TTI window [RA_WINDOW_BEGIN— RA_WINDOW_END], 
or if all received Random Access Responses contain Random Access Preamble identifiers that do not match the 
transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the UE 
shall: 

if the Random Access procedure was initiated by the MAC sublayer itself; or 

if the Random Access procedure was initiated by a PDCCH order and the 
PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1 ; 

- proceed to the selection of a Random Access Resource (see subclause 5.1.2). 
Editor's note: Whether error conditions are specified is FFS. 



7.1.2.5.3 
7.1.2.5.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 

System information are set according to table 7.1.2.4.3.3-1 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 
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7.1.2.5.3.2 



Test procedure sequence 



Table 7.1.2.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a Paging message including 
a matched identity. 


- 


- 


- 


- 


2 


Checl<: does the UE transmit a preamble on 
PRACH 


— > 


PRACH Preamble 


1 


P 


3 


The SS transmits a IVIAC PDU addressed to 
UE RA-RNTI, containing multiple RAR's but 
none of the MAC sub headers contains a 
matching RAPID 


<— 


Random Access Response 








EXCEPTION: In parallel with step 4, parallel 
behaviour defined in table 7.1 .2.5.3.2-3 is 
executed 










4 


Check: does the UE re-transmit a preamble on 
PRACH 


— > 


PRACH Preamble 


1 


P 


5 


The SS transmits a IVIAC PDU addressed to 
UE RA-RNTI, containing multiple RAR's one 
of the MAC sub headers contains a matching 
RAPID 


<— 


Random Access Response 






6 


The UE transmits an RRCConnectionRequest 
message. 


- 


MAC PDU 


2 


- 


7 


The SS sends a MAC PDU containing 
matching Contention Resolution Identity MAC 
control element 


<— 


MAC Control PDU 







Table 7.1.2.5.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE transmits an RRCConnectionRequest 
message. 


- 


MAC PDU 


1 


F 



7.1.2.5.3.3 
None. 



Specific message contents 



7.1 .2.6 Maintenance of Uplink Time Alignment 

7.1.2.6.1 Test Purpose (TP) 

(1) 

with {UE in E-UTRA RRC_IDLE state and having initiated a random access procedure) 
ensure that { 

when { The SS transmits a Timing Alignment Command in a Random Access Response message} 
then {the UE applies the received Timing Advance value in the next transmitted MAC PDU} 
} 

(2) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when { Timing Advanced MAC control Element is received and UE has pending data during the period 
the Time Alignment timer is running} 

then { UE does not send any Random Access Preamble, but Scheduling Requests to request 
transmission of data while Time Alignment timer is running} 
} 

(3) 



with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 55 ETSI TS 136 523-1 V8.0.1 (2009-01) 

when{ {Timing Alignment timer has expired or is not running and UL transmission is required) } 
then {UE triggers a RA Procedure} 



7.1.2.6.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321 clause 5.2. 

[TS 36.321 clause 5.2] 

The UE has a configurable Time Alignment Timer. The Time Alignment Timer is valid only in the cell for which it was 
configured and started. 

If the Time Alignment Timer has been configured, the UE shall: 

when a Timing Advance MAC control element is received: 

apply the Timing Advance Command; 

start the Time Alignment Timer (if not running) or restart the Time Alignment Timer (if already running). 

when a Time Alignment Command is received in a Random Access Response message: 

if the Random Access Preamble and PRACH resource were explicitly signalled: 

apply the Time Alignment Command; 

start the Time Alignment Timer (if not running) or restart the Time Alignment Timer (if already running). 

else, if the Time Alignment Timer is not running or has expired: 

apply the Time Alignment Command; 

start the Time Alignment Timer; 

when the contention resolution is considered not successful as described in subclause 5.1.5, stop the Time 
Alignment Timer. 

else: 

ignore the received Time Alignment Command. 

when the Time Alignment Timer has expired or is not running: 

prior to any uplink transmission, use the Random Access procedure (see subclause 5.1) in order to obtain 
uplink Time Alignment. 

when the Time Alignment Timer expires: 

flush all HARQ buffers and consider the next transmission for each process as the very first transmission; 

release all PUCCH resources; 

release any assigned SRS resources. 



7.1.2.6.3 


Test description 


7.1.2.6.3.1 


Pre-test condition 


System Simulator 




- Cell 1 




UE 




None. 
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Preamble 



The generic procedure to get UE in state Idle mode (state 2)Loopback Activated (State 4) according to TS 
36.508 clause 4.5 is executed. 



7.1.2.6.3.2 



Test procedure sequence 



Table 7.1.2.6.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 




1 


SS pages the UE 


- 


- 


- 


- 


2 


SS respond to UE Random Access request 
by a Random Access Response with TA field 
within message set to 600 (Note 2). 


<— 


IVIAC PDU(Random Access 
Response (TA=600)) 






3 


Check: Does UE send an 
RRCConnectionRequest message in the first 
scheduled UL transmission using the Timing 
Advance value sent by the SS in step 2? 


— > 


MAC PDU 

( RRCConnectionRequest) 


1 


P 


4 


RA Procedure considered a success. 


<~ 


MAC PDU (UE Contention 
Resolution Identity) 


- 


- 


5 


The SS sends an RRCConnectionSetup 
message. 


<— 


MAC PDU (RRCConnectionSetup) 


- 


- 


6 


Check: does the UE transmit an 
RRCConnectionSetupComplete? 


— > 


MAC PDU 

( RRCConnectionSetupCompiete) 


1 


P 


7 


The generic procedure to get UE in test state 
Loopback Activated (State 4) according to 
TS 36.508 clause 4.5 is executed with UL 
SDU size set to '0' (no data returned in 
uplink) 










8 


SS transmits Timing Advance command. SS 
does not send any subsequent alignments. 
SS Starts Timer_1 = 0.8 * Time Alignment 
Timer 


<— 


MAC PDU (Timing Advance MAC 
Control Element) 






9 


SS sends a IVIAC PDU containing a RLC 
PDU with SN=0 and poll bit set to trigger UE 
to transmit a status report in uplink. SS does 
not respond to any scheduling requests or 
Random Access Preambles from the UE. 


<— 


MAC PDU (RLC PDU) 






10 


Check: Does UE transmit Scheduling 
Requests, but no Random Access Preamble 
message while Timer 1 is running? 
(Note 1) 


--> 


(SR) 


2 


P 


11 


SS waits 0.2* Time Alignment Timer 


- 


- 


- 


- 


12 


Check: UE transmits a Random Access 
Preamble 


— > 


Random Access Preamble 


3 


P 


13 


SS responds with a valid Random Access 
Response 


<— 


MAC PDU (Random Access 
Response (C-RNTI)) 


- 


- 


14 


Check: The UE successfully transmits an 
RLC STATUS PDU for the 
acknowledgement of the DL Data with the 
Temporary C-RNTI set to the value of C- 
RNTI received in the Random Access 
Response message 


— > 


MAC PDU(RLC STATUS PDU 
(ACK_SN=1)) 


3 


P 


15 


The SS Transmits a valid IVIAC PDU 
including 'UE Contention Resolution Identity' 
IVIAC control element with matching 
'Contention Resolution Identity' 


<— 


MAC PDU(Matching UE Contention 
Resolution Identity) 






Note 1 A conformant UE correctly applies Timing Advance MAC Control and restarts the Timing Alignment timer, 
causing the uplink to stay in sync for a period equal to the received Time Alignment Value. 

Note 2 TA value of 600 has been chosen arbitrary in the middle of the range to 1282 and corresponds to 0.3125 
ms (timing advance in ms = 1000 x NTA x TS where NTA = TA x 16 and TS = 1 / (15000x2048) according 
to TS 36.21 3 and TS 36.211). 



7.1.2.6.3.3 



Specific Message Contents 



None. 
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7.1 .2.7 MAC-Contention Resolution [Temporary C-RNTI] 

7.1.2.7.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 

when { SS does not send any MAC PDU including 'UE Contention Resolution Identity' MAC control 
element before contention resolution timer expires } 
then { UE transmits a random access preamble} 

} 

(2) 

with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 

when { SS transmits a valid MAC PDU containing RRCConnectionSetup, but not including 'UE 
Contention Resolution Identity' MAC control element } 
then { UE transmits a random access preamble } 

} 

(3) 

with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 

when { SS transmits a valid MAC PDU containing RRCConnectionSetup, including 'UE Contention 
Resolution Identity' MAC control element but with un-matched 'Contention Resolution Identity' } 
then { UE transmits a random access preamble } 

} 

(4) 

with { UE in E-UTRA RRC_IDLE state and after transmitting a RRCConnectionRequest message} 
ensure that { 

when { SS transmits a valid MAC PDU containing a RRCConnectionSetup, including 'UE Contention 
Resolution Identity' MAC control element and matching 'Contention Resolution Identity' } 
then { UE transmits a RRCConnectionSetupComplete message} 
} 

7.1.2.7.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.1.5. 

[TS 36.321, clause 5.1.5] 

Contention Resolution is based on C-RNTI on PDCCH and UE Contention Resolution Identity on DL-SCH.. 

Once the uplink message containing the C-RNTI MAC control element or the uplink message including the CCCH 
SDU is transmitted, the UE shall: 

start the Contention Resolution Timer; 

regardless of the possible occurrence of a measurement gap, monitor the PDCCH until the Contention 
Resolution Timer expires; 

if notification of a reception of a PDCCH transmission is received from lower layers, the UE shall: 



else if the uplink message included the CCCH SDU and the PDCCH transmission is addressed to its 
Temporary C-RNTI: 

if the MAC PDU is successfully decoded: 

stop the Contention Resolution Timer; 

if the MAC PDU contains a UE Contention Resolution Identity MAC control element; and 

if the UE Contention Resolution Identity included in the MAC control element matches the CCCH 
SDU transmitted in the uplink message: 
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consider this Contention Resolution successful and finish the disassembly and demultiplexing of 
the MAC PDU; 

- set the C-RNTI to the value of the Temporary C-RNTI; 

consider this Random Access procedure successfully completed. 

else 

consider this Contention Resolution not successful and discard the successfully decoded MAC 
PDU. 

discard the Temporary C-RNTI. 

if the Contention Resolution Timer expires: 

consider the Contention Resolution not successful, 
if the Contention Resolution is considered not successful the UE shall: 

if the Random Access procedure was initiated by the MAC sublayer itself; or 

if the Random Access procedure was initiated by a PDCCH order and the 
PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1 ; 

based on the backoff parameter in the UE, select a random backoff time according to a uniform 
distribution between and the Backoff Parameter Value; 

delay the subsequent Random Access transmission by the backoff time; 

proceed to the selection of a Random Access Resource (see subclause 5.1.2). 

discard the Temporary C-RNTI. 

7.1.2.7.3 Test description 

7.1.2.7.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

RACH parameters in SIB2 as indicated in table 7.1.2.7.3.1-1. 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 
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Table 7.1 .2.7.3.1-1: RACH Parameters 



Parameter 


Value 


PREAMBLE TRANS MAX 


Max allowed value 


Contention Resolution Timer 


FFS 


Backoff timer in UE 


0ms 



7.1.2.7.3.2 



Test procedure sequence 



Table 7.1.2.7.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a Paging message including 
a matched identity. 


- 


- 


1 


- 


2 


The UE transmits a MAC PDU containing an 
RRCConnectionRequest message. 


— > 


MAC PDU 


1 


- 


3 


Check: For time equal to 'Contention 
Resolution Timer', does UE send a PRACH 
preamble? 




PRACH preamble 


1 


F 


4 


Check: does the UE transmit a MAC PDU 
containing an RRCConnectionRequest 
message? 


— > 


MAC PDU 


1 


P 




EXCEPTION: In parallel with steps 5 to 8, the 
parallel behaviour in table 7.1 .2.7.3.2-2 is 
running. 










5 


The SS Transmits a valid MAC PDU 
containing RRCConnectionSetup, but not 
including 'UE Contention Resolution Identity' 
MAC control element 


<— 


MAC PDU 


2 




6 


Check: does the UE transmit a MAC PDU 
containing an RRCConnectionRequest 
message? 


— > 


MAC PDU 


2 


P 


7 


The SS Transmits a valid MAC PDU 
containing RRCConnectionSetup, and 
including 'UE Contention Resolution Identity' 
MAC control element but with un matched 
'Contention Resolution Identity' 


<— 


MAC PDU 


3 




8 


Check: does the UE transmit a MAC PDU 
containing an RRCConnectionRequest 
message? 


— > 


MAC PDU 


3 


P 


9 


The SS Transmits a valid MAC PDU 
containing RRCConnectionSetup, and 
including 'UE Contention Resolution Identity' 
MAC control element with matching 
'Contention Resolution Identity' 


<— 


MAC PDU 


4 




10 


Check: does the UE transmit a MAC PDU 
containing an RRCConnectionSetupComplete 
message? 


— > 


MAC PDU 


4 


P 



Table 7.1.2.7.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Check: UE transmits a MAC PDU containing 
an RRCConnectionSetupComplete message 
indicating acceptance of 
RRCConnectionSetup message 


— > 


MAC PDU 


2,3 


F 
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7.1.2.7.3.3 



Specific message contents 



7.1 .2.7.3.3-1 : SystemlnformationBlockType2 (all steps, table 7.1 .2.7.3.2-1 )Derlvation path: 36.508 table 4.4.3.3-1 



Information Element 



Value/Remark 



Comment 



Condition 



SystemlnformationBlockType2 ::= SEQUENCE { 
radioResourceConfigCommon SEQUENCE { 
rach-Configuration SEQUENCE { 
ra-Supervisionlnformation SEQUENCE { 
preambleTransMax 
mac-ContentionResolutionTimer 
} 
} 
} 
A 



N10 
sf64 



Max value 
Max value 



7.1 .2.8 MAC-Contention Resolution [ C-RNTI ] 

7.1.2.8.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state and after transmitting a 

RRCConnectionReconfigurationComplete message for a handover without dedicated preamble} 
ensure that { 

when { The SS does not schedule any PDCCH transmission addressed to UE C-RNTI before Contention 
resolution timer expiry} 

then { The UE retransmits the RRCConnectionReconf igrationComplete message} 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state and after transmitting a 

RRCConnectionReconf igurationComplete message for a handover without dedicated preamble } 

ensure that { 

when { UE receive PDCCH transmission addressed to its C-RNTI before Contention resolution timer 
expiry } 

then { The UE does not retransmit the RRCConnectionReconf igrationComplete message } 

} 

7.1.2.8.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.1.5. 

[TS 36.321, clause 5.1.5] 

Contention Resolution is based on C-RNTI on PDCCH and UE Contention Resolution Identity on DL-SCH.. 

Once the uplink message containing the C-RNTI MAC control element or the uplink message including the CCCH 
SDU is transmitted, the UE shall: 

- start the Contention Resolution Timer; 

regardless of the possible occurrence of a measurement gap, monitor the PDCCH until the Contention 
Resolution Timer expires; 

if notification of a reception of a PDCCH transmission is received Irom lower layers, the UE shall: 

if the C-RNTI MAC control element was included in uplink message: 

if the Random Access procedure was initiated by the MAC sublayer itself and the PDCCH transmission is 
addressed to the C-RNTI and contains an UL grant; or 

if the Random Access procedure was initiated by a PDCCH order and the PDCCH transmission is 
addressed to the C-RNTI: 

consider this Contention Resolution successful; 

stop the Contention Resolution Timer; 
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discard the Temporary C-RNTI; 

consider this Random Access procedure successfully completed. 

else 

consider this Contention Resolution not successful and discard the successfully decoded MAC 
PDU. 

discard the Temporary C-RNTI. 

if the Contention Resolution Timer expires: 

consider the Contention Resolution not successful, 
if the Contention Resolution is considered not successful the UE shall: 

if the Random Access procedure was initiated by the MAC sublayer itself; or 

if the Random Access procedure was initiated by a PDCCH order and the 
PREAMBLE_TRANSMISSION_COUNTER is less than PREAMBLE_TRANS_MAX: 

- increment PREAMBLE_TRANSMISSION_COUNTER by 1 ; 

based on the backoff parameter in the UE, select a random backoff time according to a uniform 
distribution between and the Backoff Parameter Value; 

delay the subsequent Random Access transmission by the backoff time; 

proceed to the selection of a Random Access Resource (see subclause 5.1.2). 

discard the Temporary C-RNTI. 

7.1 .2.8.3 Test description 

7.1.2.8.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 

System information as in table 7.1.2.8.3.3-1. 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on cell 1. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



62 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



7.1.2.8.3.2 



Test procedure sequence 



Table 7.1.2.8.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a MAC PDU containing an 
RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2, not including explicit 
Random Access Preamble. 


<— 


MAC PDU 






2 


The UE transmits on cell 2 a MAC PDU 
containing 

RRCConnectionReconfigurationComplete., 
including C-RNTI MAC control element 


— > 


MAC PDU 






3 


SS Does not schedule any PDCCH 
transmission for UE C-RNTI 


- 


- 


- 


- 


4 


Check: does the UE transmit a PRACH 
preamble within time equal to 'Contention 
Resolution Timer'? 


— > 


(PRACH preamble) 


1 


F 


5 


Check: does the UE transmit on cell 2 a MAC 
PDU containing 

RRCConnectionReconfigurationComplete, 
including C-RNTI MAC control element? 


— > 


MAC PDU 


1 


P 


6 


SS sends PDCCH transmission for UE C-RNTI 


- 


- 


- 


- 


7 


Check: does the UE transmit MAC PDU 
containing 

RRCConnectionReconfigurationComplete 
within the next 2s? 


— > 


MAC PDU 


2 


F 


8 


Check: does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2? 











7.1 .2.8.3.3 Specific message contents 

Table 7.1.2.8.3.3-1: SystemlnformationBlockType2(a\\ steps, Table 7.1.2.8.3.2-1) 



Derivation path: 36.508 table 4.4.3.3-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 
radioResourceConfigCommon SEQUENCE { 
rach-Configuration SEQUENCE { 
ra-Supervisionlnformation SEQUENCE { 
preambleTransMax 
mac-ContentionResolutionTimer 

} 
} 
} 
} 


N10 
sf64 


Max value 
Max value 
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Table 7.1.2.8.3.3-2 RRCConnectionReconfiguration (step 1, Table 7.1.2.8.3.2-1) 



Derivation path: 36.508 table 4.6.1-6, condition RBC-HO | 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 
criticalExtensions CHOICE { 
c1 CHOICE! 
rrcConnectionReconfiguration-r8 SEOUENCE { 
mobilityControllnformation SEQUENCE { 

targetCellldentity 

eutra-CarrierFreq 

} 
} 
} 
} 
} 


MobilityControllnformatio 
n-HQ 

PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 
Not present 







7.1.2.9 MAC-Backoff Indicator 

Editor's note: This test case is not based on 36.321 v8.3.0. 



7.1.2.9.1 



Test Purpose (TP) 



(1) 

with {UE in E-UTRA RRC_IDLE state and having initiated a random access procedure) 
ensure that{ 

when { SS sends a Random Access Response including a Backoff Indicator but Random Access 
Preamble identifier is different from the value received from the UE } 
then{ UE does not send any RRC connection request } 
} 

(2) 

with {UE in E-UTRA RRC_IDLE state and having initiated a random access procedure) 
ensure that { 

when { SS sends a Random Access Response that does not contain an Backoff Indicator} 

then{ UE sends a RRC connection request in the first scheduled UL transmission } 
} 

(3) 

with {UE in E-UTRA RRC_IDLE state and having initiated a random access procedure) 
ensure that { 

when { { SS sends a Random Access Response contains Backoff Indicator and a Random Access 
Preamble identifier with the same value as received from the UE } 

then{ UE sends a RRC connection request before time equal to the Backoff Parameter Value 
expires } 



6.1.2.8.2 



Conformance requirements 



Editor's note: The conformance requirement is based on CR R2-083688 to TS 36.321 v8.2.0 that was agreed in 
principle at RAN2#62-BIS meeting 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clauses 5.1.4 and 7.2. 

[TS 36.321 clause 5.1.4] 

If notification of a reception of the Random Access Response is received from lower layers, the UE shall: 

if the Random Access Response contains a Backoff Indicator sub header: 

set the backoff parameter value in the UE as indicated by the Bl field of the Backoff Indicator sub header 
and Table 7.2-1. 
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else, set the backoff parameter value in the UE to ms. 



If no Random Access Response is received within the TTI window [RA_WINDOW_BEGIN— RA_WINDOW_END], 
or if all received Random Access Responses contain Random Access Preamble identifiers that do not match the 
transmitted Random Access Preamble, the Random Access Response reception is considered not successful and the UE 
shall: 



if in this Random Access procedure: 

the Random Access Preamble was selected by MAC; or 

the Random Access Preamble and PRACH resource were explicitly signalled and will expire before the 
next available Random Access occasion: 

based on the backoff parameter in the UE, select a random backoff time value according to a uniform 
distribution between and the Backoff Parameter Value; 

delay the subsequent compute and apply a backoff value indicating when a new Random Access 
transmission by the backoff time according to the backoff value shall be attempted; 

[TS 36.321 clause 7.2] 

Backoff Parameter values are presented in Table 7.2-1. 

Table 7.2-1 : Backoff Parameter values. 



Index 


Backoff Parameter value (ms) 








1 


10 


2 


20 


3 


30 


4 


40 


5 


60 


6 


80 


7 


120 


8 


160 


9 


240 


10 


320 


11 


480 


12 


960 



7.1.2.9.3 




7.1.2.9.3.1 




System Simi 


ilator 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 



Preamble 

Random Access settings in SystemInformationBlockType2 are as specified in specific message content. 
The UE is in state Registered, Idle Mode (state 2) according to [18]. 
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Table 7.1.2.9.3.1-1: Random Access Settings in SystemlnformationBlockType2 



FFS 



7.1.2.9.3.2 



Test procedure sequence 



Table 7.1.2.9.3.2-1 : Backoff Parameter values. 



x: Index 


Y: Backoff Parameter value (ms) 








1 


10 


2 


20 


3 


30 


4 


40 


5 


60 


6 


80 


7 


120 


8 


160 


9 


240 


10 


320 


11 


480 


12 


960 
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Table 7.1.2.9.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 1 


U-S 


Message 






EXCEPTION: Steps 1 to 4 are repeated for 
values of 'x' and 'y' according to table 
7.1.2.9.3.2-1 










1 


SS page the UE 


- 


- 


- 


- 


2 


Check: Does UE send a Random Access 
Preamble? 


— > 


Random Access Preamble 


1 


P 


3 


SS sends a Random Access Response with 
the backoff parameter set to value Index field 
'x' and with the Random Access Preamble 
identifier different from the value received from 
the UE in the Random Access Preamble. 
The SS sets Timer_T1 to the Backoff value 'y' 
associated with the Index value 'x' and starts 
Timer T1. 


<- 


Random Access Response(BI, 
RAPID) 






4 


Check: Does UE send any 
RRCConnectionRequest while Timer_T1 is 
running? 






1 


F 


5 


SS stops Timer_T1 and responds with a 
Random Access Response with no back-off 
indicator set and the Random Access 
Preamble identifier value set to the same value 
as received from the UE in the Random 
Access Preamble. 


<— 


Random Access 
Response(RAPID) 






6 


Check: Does UE send an 
RRCConnectionRequest message in the first 
scheduled UL transmission? 


— > 


MAC PDU 

( RRCConnectionRequest) 


2 


P 


7 


The SS sends a Contention Resolution Failure. 


<— 


MAC PDU (Un matching UE 
Contention Resolution Identity) 


- 


- 




EXCEPTION: Steps 8 to 1 1 are repeated for 
values of 'x' and 'y' according to table 
7.1.2.9.3.2-1 










8 


Check: Does UE send a Random Access 
Preamble? 


— > 


Random Access Preamble 


3 


P 


9 


SS sends a Random Access Response with a 
backoff parameter set to value Index field 'x' 
and the Random Access Preamble identifier 
value set to the same value as received from 
the UE in the Random Access Preamble. The 
SS sets Timer_T1 to the Backoff value 'y'+ 
[TBD ms] associated with the Index value 'x' 
and starts Timer T1. 


<— 


Random Access Response(BI, 
RAPID) 






10 


Check: Does UE send an 
RRCConnectionRequest whWe Timer_T1 is 
running? 


— > 


MAC PDU 

( RRCConnectionRequest) 


3 


P 


11 


The SS sends a Contention Resolution Failure. 


<— 


MAC Control PDU (Un 
matching UE Contention 
Resolution Identity) 







Editor's note: In steps 4 and 5, SS behaviour is unclear, as step 
and the step 5 seems to be a response matching with 
could be useful to clarify. 



4 does not describe the Random Access Preamble, 
Random Access Preamble in step 2. At least a note 



7.1.2.9.3.3 
None 



Specific Message Contents 
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7. 1 .3 DL-SCH Data transfer 

7.1 .3.1 Correct handling of DL assignment / dynamic case 

7.1.3.1.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives downlink assignment on the PDCCH for the UE's C-RNTI and receives data in the 
associated subframe and UE performs HARQ operation } 

then { UE sends a HARQ feedback on the HARQ process } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives downlink assignment on the PDCCH with a C-RNTI unknown by the UE and data is 
available in the associated subframe } 

then { UE does not send any HARQ feedback on the HARQ process } 
} 

7.1 .3.1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clause 5.3.1 

[TS 36.321, clause 5.3.1] 

Downlink assignments transmitted on the PDCCH indicate if there is a transmission on the DL-SCH for a particular UE 
and provide the relevant HARQ information. 

When the UE has a C-RNTl, Semi-Persistent Scheduling C-RNTI, Temporary C-RNTI or RA-RNTI, the UE shall for 
each TTI during Active Time, for each TTl when a Random Access Response or Contention Resolution is expected and 
for each TTI for which a DL assignment has been configured: 

if a downlink assignment for this TTI has been received on the PDCCH for the UE's C-RNTI, Temporary 
C-RNTI: 

indicate the presence of a downlink assignment and the associated HARQ information to the HARQ entity 
for this TTI. 



Editor's note: LI is configured, as needed, by upper layers or MAC [FFS] to monitor PDCCH for C-RNTI, and by 
MAC to monitor PDCCH for Temporary C-RNTI and RA-RNTI. 



7.1.3.1.3 


Test description 


7.1.3.1.3.1 


Pre-test conditions 


System Simulator 




- Cell 1 




UE: 




None. 




Preamble 





The generic procedure to get UE in test state Loopback Activated (State 4) according to TS 36.508 clause 4.5 is 
executed, with all the parameters as specified in the procedure except that the RLC SDU size is set to return no 
data in uplink. 
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7.1.3.1.3.2 



Test procedure sequence 



Table 7.1.3.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


SS transmits a downlink assignment including 
the C-RNTI assigned to the UE 


<— 


(PDCCH (C-RNTI)) 


- 


- 


2 


SS transmits in the indicated downlink 
assignment a RLC PDU in a MAC PDU. 


<— 


MAC PDU 


- 


- 


3 


Check: Does the UE transmit an HARQ ACK 
on PUCCH? 


— > 


HARQ ACK 


1 


P 


4 


SS transmits a downlink assignment to 
including a C-RNTI different from the assigned 
totheUE 


<— 


(PDCCH (unknown C-RNTI)) 






5 


SS transmits in the indicated downlink 
assignment a RLC PDU in a MAC PDU. 


<— 


MAC PDU 


- 


- 


6 


Check: Does the UE send any HARQ ACK on 
PUCCH? 


— > 


HARQ ACK 


2 


F 



Specific Message Contents 

Correct handling of DL assignment: semi persistent case 

Test Purpose (TP) 



7.1.3.1.3.3 
None. 

7.1.3.2 

7.1.3.2.1 
(1) 

with { UE in E-UTRA RRC_Connected state with DRB established} 
ensure that { 

when { UE receives a DL assignment addressed to its SPS-CRNTI in sub-frame y and with NDI set as 

} 

then { UE starts receiving DL MAC PDU in sub frames y+4+n* [semiPersistSchedlntervalDL] where 

'n' is positive integer starting at zero} 
} 

(2) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored DL SPS grant to receive MAC 
PDU at subframe y+4+n* [semiPersistSchedlntervalDL] } 
ensure that { 

when { UE receives a DL assignment addressed to its SPS-CRNTI in sub-frame p and with NDI set as 
0, where p!= y+n* [semiPersistSchedlntervalDL] } 

then { UE starts receiving DL MAC PDU in sub frames p+4+n* [semiPersistSchedlntervalDL] and 
stops receiving DL MAC PDU at sub frames y+4+n* [semiPersistSchedlntervalDL] where 'n' is positive 
integer statriting at zero} 

(3) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored DL SPS grant to receive MAC 
PDU at subframe p+4+n* [semiPersistSchedlntervalDL] } 
ensure that { 

when { UE receives a DL assignment [for retransmission] addressed to its SPS-CRNTI in sub-frame z 
and with NDI set as 1, where z!= p+n* [semiPersistSchedlntervalDL] } 

then { UE receives MAC PDU in sub frame z+4 as per the new grant for SPS-CRNTI } 

(4) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored DL SPS grant to receive MAC 
PDU at subframe z+4+n* [semiPersistSchedlntervalDL] } 
ensure that { 

when { UE receives a DL assignment addressed to its CRNTI in sub- frame p, such that p+4= 
z+4+n* [semiPersistSchedlntervalDL] } 

then { UE receives MAC PDU in sub frame p+4 as per grant addresed to its C-RNTI } 
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(5) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored DL SPS grant to receive MAC 
PDU at subframe z+4+n* [semiPersistSchedlntervalDL] } 
ensure that { 

when { UE receives a RRCConnectionReconf iguration including the mobilityControlInformation and 
hence resulting in SPS grant deactivation} 

then { UE stops receiving DL MAC 
PDU' s as per stored SPS grant in sub frame z+4+n* [semiPersistSchedlntervalDL] } 

} 

Editors note: SPS Grant deactivation is not very clear 

7.1.3.2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321 clause 5.3.1 and 
36.331 clause 5.3.10.5. 

[TS 36.321, clause 5.3.1] 

Downlink assignments transmitted on the PDCCH indicate if there is a transmission on the DL-SCH for a particular UE 
and provide the relevant HARQ information. 

When the UE has a C-RNTI, Semi-Persistent Scheduling C-RNTI, or Temporary C-RNTI, the UE shall for each TTI 
during Active Time, for each TTI when a Random Access Response or Contention Resolution is expected and for each 
TTI for which a DL assignment has been configured: 

if a downlink assignment for this TTI has been received on the PDCCH for the UE's C-RNTI, or Temporary 
C-RNTI: 

indicate the presence of a downlink assignment and deUver the associated HARQ information to the HARQ 
entity for this TTI. 

else, if a downlink assignment for this TTI has been received on the PDCCH for the UE's Semi-Persistent 
Scheduling C-RNTI: 

if the NDI in the received HARQ information is 1: 

consider the NDI not to have been toggled; 

indicate a downlink assignment and the associated HARQ information to the HARQ entity for this TTI. 
else, if the NDI in the received HARQ information is 0: 

store the downlink assignment and the associated HARQ information as configured downlink assignment; 

initialise (if not active) or re-initialise (if already active) the configured downlink assignment to start in 
this TTI and to recur with the periodicity configured via RRC; 

- set the HARQ Process ID to [the HARQ Process ID associated with this TTI]; 

consider the NDI bit to have been toggled; 

indicate the presence of a configured downUnk assignment and deliver the stored HARQ information to 
the HARQ entity for this TTI. 

- else, if [PDCCH condition for deactivation of SPS]: 

clear the configured downlink assignment (if any). 

else, if a downlink assignment for this TTI has been configured: 

instruct the physical layer to receive, in this TTI, transport(s) block on the DL-SCH according to the 
configured downlink assignment and to deliver it to the HARQ entity; 

- set the HARQ Process ID to [the HARQ Process ID associated with this TTI]; 

consider the NDI bit to have been toggled; 
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indicate the presence of a configured downlink assignment and deliver the stored HARQ information to the 
HARQ entity for this TTI. 

[TS 36.331, clause 5.3.10.5] 

Authors Note: Is this allowed? 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 



7.1.3.2.3 


Test description 


7.1.3.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 

The loop back size is set in such a way that one RLC SDU in DL shall result in 1 RLC SDU's in UL of same 
size. 

Following specific parameters in table 7.1.3.2.3.1-1 are allocated to the UE during preamble. 

Table 7.1.3.2.3.1-1 : specific Parameters in RRCConnectionReconfiguration 



Parameter 


Value 


semiPersistSchedlntervalDL 


sf160 


Semi-Persistent Scheduling C-RNTI 


FFS* 



Editors Note: It is not yet clear how the SPS C-RNTI is assigned to UE. 
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7.1.3.2.3.2 



Test procedure sequence 

Table 7.1.3.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS Transmits a DL assignment using UE's 
SPS C-RNTI in sub frame 'Y', NDI=0 


<- 


(DL SPS Grant) 


- 


- 


2 


The SS transmits in sub frame 'Y+4', DL IVIAC 
PDU containing a RLC PDU [DL-SQN=0]on 
DRB 


<- 


MAC PDU 






3 


Checl<: Does the UE transmit a HARQ ACK? 


— > 


HARQ ACK 


1 


P 


4 


The SS transmits in sub frame 
'Y+4+X[semJPersistSchedlntervalDL]', DL 
MAC PDU containing a RLC PDU [DL- 
SQN=1]onDRB 


<- 


MAC PDU 






5 


Checl<: Does the UE transmit a HARQ ACK? 


— > 


HARQ ACK 


1 


P 


6 


The SS Transmits a DL assignment using UE's 
SPS C-RNTI in sub frame 'P', NDI=0; 
[Where Y+X<P< Y+2X] 


<- 


(DL SPS Grant) 






7 


The SS transmits in sub frame 'P+4', DL IVIAC 
PDU containing a RLC PDU [DL-SQN=2]on 
DRB 


<- 


MAC PDU 






8 


Check: Does the UE transmit a HARQ ACK? 


— > 


HARQ ACK 


2 


P 


9 


The SS transmits in sub frame 'Y+4+2X', DL 
IVIAC PDU containing a RLC PDU [DL- 
SQN=3]on DRB 


<- 


MAC PDU 






10 


Check: Does the UE transmit a HARQ 
Feedback? 


-> 


HARQ ACK/NACK 


2 


F 


11 


The SS transmits in sub frame 'P+ 
4+X[semiPersistSchedlntervalDL]', DL IVIAC 
PDU containing a RLC PDU [DL-SQN=3]on 
DRB; CRC is calculated in such a way will 
result in CRC error in UE. 


<- 


MAC PDU 






12 


Check: Does the UE transmit a HARQ NACK? 


— > 


HARQ NACK 


2,3 


P 


13 


The SS Transmits a DL assignment using UE's 
SPS C-RNTI in sub frame 'Z', NDI=1 ; 
Where [P < Z <P-h1X]; The DL HARQ process 
is same as in step 11 


<— 


(DL SPS Grant) 






14 


The SS re-transmits in sub frame 'Z+4', DL 
IVIAC PDU containing a RLC PDU [DL- 
SQN=3]on DRB; 


<- 


MAC PDU 






15 


Check: Does the UE transmit a HARQ ACK? 


— > 


HARQ ACK 


3 


P 


16 


The SS transmits in sub frame 
'P-H4-H2X[semiPersistSchedlntervalDL]', DL 
IVIAC PDU containing a RLC PDU [DL- 
SQN=4]on DRB 


<- 


MAC PDU 






17 


Check: Does the UE transmit a HARQ ACK? 


— > 


HARQ ACK 


1 


P 


18 


The SS Transmits a DL assignment using UE's 
C-RNTI in sub frame 
'P-H3X[semJPersistSchedlntervalDL]' 


<- 


(DL Grant) 






19 


The SS transmits in sub frame 
'P-H4-H3X[semiPersistSchedlntervalDL]', DL 
MAC PDU containing 1 RLC PDU's [DL- 
SQN=4]on DRB; Size of RLC PDU is different 
than all previous PDU's 


<- 


MAC PDU 






20 


Check: Does the UE transmit a HARQ ACK ? 


— > 


HARQ ACK 


4 


P 


21 


SS transmits an UL Grant sufficient for 
transmitting loop back PDU's corresponding to 
DL RLC PDU's with SQN's to 4 


<— 


(UL Grant) 






22 


The UE MAC PDU transmits loop back SDU's 
corresponding to DL RLC PDU's with SQN to 
4. 


-> 


MAC PDU 






23 


SS Transmits RRCConnectionReconfiguration 
including the mobilityControllnformation 






- 


- 
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24 


The UE transmits 
RRCConnectionReconfigurationComplete 






- 


- 


25 


The SS transmits in sub frame 
'Y+4+nX[semiPersistSchedlntervalDL]\ DL 
MAC PDU containing 1 RLC PDU's [DL- 
SQN=5]on DRB; [n>4] 


<- 


MAC PDU 






26 


Checl<: The UE transmits a HARQ Feedbacl< 


— > 


HARQ ACK/NACK 


5 


F 



Note 1: Steps 21 and 22 are executed to bring UE in stable state. 



7.1.3.2.3.3 
None. 



Specific message contents 



7.1 .3.3 MAC PDU header handling 

Editor's note: This test case is not based on 36.321 v8.3.0. 



7.1.3.3.1 

(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives a MAC PDU with a MAC header containing a Length field L value that is greater 
than the remaining MAC payload size } 

then { UE discards PDU } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives a MAC PDU where in the MAC header an Extension field E is set to "1" in the 
last MAC sub-header and there after no more MAC SDUs or padding follow } 

then { UE discards PDU } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives a MAC PDU containing one MAC SDU and two sub-headers where one contains a 
Length field L=0 } 

then { UE reads the MAC header and correctly delivers the higher layers } 
} 

(4) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives a MAC PDU with multiple sets of R/R/E/LCID fields set to correct values in the 
MAC header and containing the respective MAC SDUs and MAC control elements } 
then { UE reads the MAC header and correctly delivers the higher layers } 

} 

Editor's Note: Handling of erroneous data is FFS (TPl, TP2 and TP3) 



7.1.3.3.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clause 6.1.2 
and 6.2.1. 

[TS 36.321, clause 6.1.2] 

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC 
control elements, and optionally padding; as described in Figure 6.1.2-3. 

Both the MAC header and the MAC SDUs are of variable sizes. 
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A MAC PDU header consists of one or more MAC PDU sub-headers; each sub header corresponding to either a MAC 
SDU, a MAC control element or padding. 

A MAC PDU sub header consists of the six header fields R/R/E/LCID/F/L but for the last sub header in the MAC PDU 
and for fixed sized MAC control elements. The last sub header in the MAC PDU and sub-headers for fixed sized MAC 
control elements consist solely of the four header fields R/R/E/LCID. It follows that a MAC PDU sub header 
corresponding to padding consists of the four header fields R/R/E/LCID. 



LCID 



Oct1 
Oct 2 



R 


R 


E 


LCID 


F 


L 


L 



Octi 
Oct 2 
Oct 3 



R/R/E/LCID/F/L sub-header with 
7-bits L field 



R/R/E/LCID/F/L sub-header with 
15-bitsL field 



Figure 6.1.2-1 : R/R/E/LCID/F/L IVIAC sub header 



R R 



LCID 



Octi 



R/R/E/LCID sub-header 

Figure 6.1.2-2: R/R/E/LCID MAC sub header 

MAC PDU sub-headers have the same order as the corresponding MAC SDUs, MAC control elements and padding. 

MAC control elements, except Padding BSR, are always placed before any MAC SDU. Padding BSR occurs at the end 
oftheMACPDU. 

Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required but cannot be 
achieved by padding at the end of the MAC PDU. 

When single-byte or two-byte padding is required but cannot be achieved by padding at the end of the MAC PDU, one 
or two MAC PDU sub-headers corresponding to padding are inserted before the first MAC PDU sub header 
corresponding to a MAC SDU; or if such sub header is not present, before the last MAC PDU sub header corresponding 
to a MAC control element. 

A maximum of one MAC PDU can be transmitted per TB per UE. [Depending on the physical layer category], one or 
two TBs can be transmitted per TTI per UE. 



MAC header 



R/R/E/LCID R/R/E/LCID[/F/L] R/R/E/LCID/F/L R/R/E/LCID/F/L 
sub-header sub-header sub-header sub-header 



R/R/E/LCID/F/L R/R/E/LCID padding 
sub-header sub-header 



MAC Control 
element 1 



MAC Control 
element 2 



MAC SDU 



MAC SDU ^f^|"9 

(opt) 



-MAC payload- 



Figure 6.1.2-3: MAC PDU consisting of MAC header, MAC control elements, MAC SDUs and padding 
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[TS 36.321, clause 6.2.1] 

The MAC header is of variable size and consists of the following fields: 

LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or 
the type of the corresponding MAC control element or padding as described in tables 6.2.1-1 and 6.2. 1 -2 for the 
DL and UL-SCH respectively. There is one LCID field for each MAC SDU, MAC control element or padding 
included in the MAC PDU. The LCID field size is 5 bits; 

L: The Length field indicates the length of the corresponding MAC SDU or MAC control element in bytes. 
There is one L field per MAC PDU sub header except for the last sub header and sub-headers corresponding to 
fixed-sized MAC control elements. The size of the L field is indicated by the F field; 

F: The Format field indicates the size of the Length field as indicated in table 6.2. 1-3. There is one F field per 
MAC PDU sub header except for the last sub header and sub-headers corresponding to fixed-sized MAC control 
elements. The size of the F field is 1 bit. If the size of the MAC SDU or MAC control element is less than 128 
bytes, the UE shall set the value of the F field to 0, otherwise the UE shall set it to 1; 

E: The Extension field is a flag indicating if more fields are present in the MAC header or not. The E field is set 
to "1" to indicate another set of at least R/R/E/LCID fields. The E field is set to "0" to indicate that either a MAC 
SDU, a MAC control element or padding starts at the next byte; 

R: Reserved bits. 

The MAC header and sub-headers are octet aligned. 

Table 6.2.1-1 Values of LCID for DL-SCH 



Index 


LCID values 


00000 


CCCH 


00001 -xxxxx 


Identity of the logical channel 


xxxxx-11011 


Reserved 


11100 


UE Contention Resolution Identity 


11101 


Timing Advance 


11110 


DRX Command 


11111 


Padding 



Table 6.2.1-2 Values of LCID for UL-SCH 



Index 


LCID values 


00000 


CCCH 


00001 -yyyyy 


Identity of the logical channel 


Yyyyy-11010 


Reserved 


11011 


Power Headroom Report 


11100 


C-RNTI 


11101 


Short Buffer Status Report 


11110 


Long Buffer Status Report 


11111 


Padding 



Table 6.2.1-3 Values of F field: 

Index Size of Length field (in bits) 

7 

1 15 



Editor's note: xxxxx and yyyyy are FFS 
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7.1.3.3.3 


Test description 


7.1.3.3.3.1 


Pre-test conditions 


System Simulator 




- Cell 1 




UE: 




None. 
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Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 

SS sets the downlink and uplink shared channel configuration transport block size (TBS) to accommodate one 
MAC PDU packet plus PDCP/RLC/MAC header without padding. 

Editor's note: there is no information towards what should be the size of a MAC PDU allocated. Should it be so that 
in each test step where data are transmitted, all the data can be transmitted in a single MAC PDU (e.g. 
RLC PDUs are all concatenated)? 



7.1.3.3.3.2 



Test procedure sequence 



Table 7.1.3.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 1 


U-S 


Message 




1 


The SS transmits a RLC SDU contained in a 
MAC PDUs with the respective MAC sub- 
header containing a value of the Length field L 
= X that is greater than the max MAC SDU size 
= y (where x > y). 


<— 


MAC PDU with incorrect header 
(L > MAC SDU size) (containing a 
RLC PDU) 


1 




2 


Check: Doe the UE transmit a RLC SDU for a 
period of [Is]? (Note 1) 


- 


- 


1 


F 


3 


SS sends RLC SDU contained in a MAC PDU 
where an Extension field E is set to "1 " in the 
last MAC sub-header and there after no more 
MAC SDUs or padding follow. 


<— 


MAC PDU with incorrect header 
(E) (containing a RLC PDU) 


-2 




4 


Check: Does the UE transmit a RLC SDU for a 
period of [Is]? (Note 1) 


- 


- 


2 


F 


5 


The SS transmits a RLC SDU contained in a 
MAC PDU where there are two MAC sub- 
headers and only one MAC SDU. The first 
sub-header contains Length field L "0" and the 
second sub-header contains the correct sub- 
header fields with respect to its MAC SDU. 


<— 


MAC PDU with one incorrect sub- 
header (L = 0) plus one correct 
sub-header (containing 1 RLC 
PDU) 


3 




6 


Check: Does the UE transmit a RLC SDU? 


— > 


MAC PDU with correct header 
containing only one sub-header 
(containing 1 RLC PDU) 


3 


P 


7 


The SS transmitslO RLC SDUs contained in 
MAC PDUs where the MAC header contains 
multiple sets of correctly configured MAC sub- 
headers. 


<— 


MAC PDU with correct header 
(containing 10 RLC PDUs) 


4 




8 


Check: Does the UE transmit return 10 RLC 
SDUs? 


— > 


MAC PDU with correct header 
(containing 10 RLC PDUs) 


4 


P 


Note1. Confirms UE has discarded the received MAD PDU. 



Editor's note: In step 1, description is not consistent between "procedure" and "message". Is the intention to say that 
a Length field is greater than the total MAC PDU size minus the lengths of all MAC sub headers and their 
associated MAC SDUs? 
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Editor's note: In step 6, is anything in the "message" column to be checked which is not mentioned in the procedure 
column? If so, the description should be more specific with respect to how to judge that a header is 
correct. 

7.1 .3.3.3.3 Specific Message Contents 

None 

7.1 .3.4 Correct HARQ process handling[DCCH /DTCH] 

7.1 .3.4.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established} 
ensure that { 

when { the UE receives a MAC PDU for DRB and CRC fails} 

then { the UE transmits a NACK for the corresponding HARQ process} 
} 

(2) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established} 
ensure that { 

when { the UE receives a MAC PDU retranmission for DRB, and results in CRC pass on combined data} 
then { the UE transmits an ACK for the corresponding HARQ process and delivers data to upper 
layers} 

} 

7.1.3.4.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.3.2.1 & 
5.3.2.2. 

[TS 36.321, clause 5.3.2.1] 

There is one HARQ entity at the UE which maintains a number of parallel HARQ processes. Each HARQ process is 
associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received 
on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2). 

The number of DL HARQ processes and soft buffers are specified in [5], subclause 5.1.4.1.2. 

When the physical layer is configured for spatial multiplexing [2], one or two TBs are expected per subframe. 
Otherwise, one TB is expected per subframe. 

The UE shall: 

If a downlink assignment has been indicated for this TTI: 

allocate the TBs received from the physical layer and the associated HARQ information to the HARQ 
processes indicated by the associated HARQ information. 

If a downlink assignment has been indicated for the broadcast HARQ process: 

allocate the received TB to the broadcast HARQ process. 

NOTE: In case of BCCH a dedicated broadcast HARQ process is used. 

[TS 36.321, clause 5.3.2.2] 

For each received TB and associated HARQ information, the HARQ process shall: 

if the NDI, when provided, has been toggled compared to the value of the previous received transmission for this 
HARQ process; or 

if the HARQ process is equal to the broadcast process and the physical layer indicates a new transmission; or 
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if this is the very first received transmission for this HARQ process: 

replace the data currently in the soft buffer for this HARQ process with the received data. 

if the data has not yet been successfully decoded: 

combine the received data with the data currently in the soft buffer for this HARQ process. 

if the TB size is different from the last valid TB size signalled for this HARQ process: 

the UE may replace the data currently in the soft buffer for this HARQ process with the received data, 
attempt to decode the data in the soft buffer; 
if the data in the soft buffer was successfully decoded: 

if the HARQ process is equal to the broadcast process, deliver the decoded MAC PDU to RRC. 

else, deliver the decoded MAC PDU to the disassembly and demultiplexing entity. 

generate a positive acknowledgement ( ACK) of the data in this HARQ process, 
else: 

generate a negative acknowledgement (NACK) of the data in this HARQ process. 

if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and the Contention 
Resolution is not successful (see subclause 5.1.5); or 

if the HARQ process is equal to the broadcast process; or 

if there is a measurement gap at the time of the transmission of the HARQ feedback: 

do not indicate the generated positive or negative acknowledgement to the physical layer, 
else: 

indicate the generated positive or negative acknowledgement to the physical layer. 

Test description 
Pre-test conditions 



7.1.3.4.3 




7.1.3.4.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.1.3.4.3.2 



Test procedure sequence 



Table 7.1.3.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 




EXCEPTION: Steps 1 to 8 are run 8 times 
using test parameter values as given for each 
iteration in table 7.1 .3.4.3.2.-4. 










1 


The SS indicates a new transmission on 
PDCCH and transmits a IVIAC PDU (containing 
an RLC PDU) on HARQ process X, but the 
CRC is calculated in such a way that it will 
result in CRC error on UE side. The AIVID PDU 
contains a full RLC SDU. 


<— 


MAC PDU 


1 




2 


Check: Does the UE transmit a HARQ NACK? 


-> 


HARQ NACK 


1 


P 


3 


Check: Does the UE transmit a Scheduling 
Request within 500ms after step 1 ? 


— > 


(SR) 


1 


F 


- 


EXCEPTION: Step 3 below runs in parallel 
with behaviour in table 7.1 .3.4.3.2-3. 


- 


- 


- 


- 


4 


The SS indicates a retransmission on PDCCH 
and transmits the same IVIAC PDU like step 1 , 
with CRC is calculated in such a way that it will 
result in CRC pass on UE side. 


<— 


MAC PDU 






5 


Check: Does the UE send a HARQ ACK? 


-> 


HARQ ACK 


2 


P 


6 


UE transmit a Scheduling Request on PUCCH 


— > 


(SR) 


- 


- 


7 


The SS sends an UL grant suitable for the loop 
back PDU to transmitted 


<— 


(UL Grant) 


- 


- 


8 


The UE transmit a IVIAC PDU containing the 
loop back PDU corresponding to step 1 and 4 


-> 


MAC PDU 


- 


- 



Table 7.1.3.4.3.2-2: Test Parameters 



Iteration 


HARQ process (X) 


1 





2 


1 


3 


2 


4 


3 


5 


4 


6 


5 


7 


6 


8 


7 



7.1.3.4.3.3 
None. 



Specific message contents 



7.1 .3.5 Correct HARQ process handling [CCCH] 

7.1.3.5.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_ IDLE state with RRC connection establishment procedure initiated} 
ensure that { 

when { UE receives a MAC PDU addressed to RA-RNTI } 

then { UE does not transmit ACK/NACK for the corresponding HARQ process} 
} 

(2) 

with { UE in E-UTRA RRC_ IDLE state with RRC connection establishment procedure initiated } 
ensure that { 

when { UE receives a MAC PDU addressed to T-CRNTI without UE Contention Resolution Identity 
matching the one included in the RRCConnectionRequest message } 

then { UE does not transmit a ACK for the corresponding HARQ process } 
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(3) 

with { UE in E-UTRA RRC_ IDLE state with RRC connection establishment procedure initiated } 
ensure that { 

when { UE receives a MAC PDU addressed to T-CRNTI and cannot decode properly } 
then { UE does not transmits a NACK for the corresponding HARQ } 
} 

(4) 

with { UE in E-UTRA RRC_ IDLE state with RRC connection establishment procedure initiated } 
ensure that { 

when { UE receives a MAC PDU addressed to T-CRNTI with UE Contention Resolution Identity matching 
the one included in the RRCConnectionRequest message } 

then { UE transmits an ACK for the corresponding HARQ process and delivers data to upper layers} 
} 

7.1.3.5.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.3.2.1 and 
5.3.2.2. 

[TS 36.321, clause 5.3.2.1] 

There is one HARQ entity at the UE which maintains a number of parallel HARQ processes. Each HARQ process is 
associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received 
on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2). 

The number of DL HARQ processes and soft buffers are specified in [5], subclause 5.1.4.1.2. 

When the physical layer is configured for spatial multiplexing [2], one or two TBs are expected per subframe. 
Otherwise, one TB is expected per subframe. 

The UE shall: 

If a downlink assignment has been indicated for this TTI: 

allocate the TBs received from the physical layer and the associated HARQ information to the HARQ 
processes indicated by the associated HARQ information. 

If a downlink assignment has been indicated for the broadcast HARQ process: 

allocate the received TB to the broadcast HARQ process. 

NOTE: In case of BCCH a dedicated broadcast HARQ process is used. 

[TS 36.321, clause 5.3.2.2] 

For each received TB and associated HARQ information, the HARQ process shall: 

if the NDI, when provided, has been toggled compared to the value of the previous received transmission for this 
HARQ process; or 

if the HARQ process is equal to the broadcast process and the physical layer indicates a new transmission; or 

if this is the very first received transmission for this HARQ process: 

replace the data currently in the soft buffer for this HARQ process with the received data. 

if a retransmission is indicated for this HARQ process: 

if the data has not yet been successfully decoded: 

combine the received data with the data currently in the soft buffer for this HARQ process. 

if the TB size is different from the last valid TB size signalled for this HARQ process: 

the UE may replace the data currently in the soft buffer for this HARQ process with the received data. 

- attempt to decode the data in the soft buffer; 
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if the data in the soft buffer was successfully decoded: 

if the HARQ process is equal to the broadcast process: 

- deliver the decoded MAC PDU to RRC. 

else: 

deliver the decoded MAC PDU to the disassembly and demultiplexing entity. 

generate a positive acknowledgement (ACK) of the data in this HARQ process, 
else: 

generate a negative acknowledgement (NACK) of the data in this HARQ process. 

if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and a UE the 
Contention Resolution Identity match is not indicated successful (see subclause 5.1.5); or 

if the HARQ process is equal to the broadcast process; or 

if there is a measurement gap at the time of the transmission of the HARQ feedback: 

do not indicate the generated positive or negative acknowledgement to the physical layer, 
else: 

indicate the generated positive or negative acknowledgement to the physical layer. 

7.1.3.5.3 Test description 

7.1.3.5.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

System information taking into account parameters in table 7.1.3.5.3.3-1 

UE: 
None. 

Preamble: 

- The UE is in state Registered, Idle mode state (state 2) according to [18]. 
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7.1.3.5.3.2 



Test procedure sequence 



Table 7.1.3.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a Paging message Including 
a matched identity. 


- 




1 


- 


2 


The UE transmits Preamble on PRACH 


— > 


PRACH Preamble 


1 


- 


3 


The SS transmits Random Access Response 
with matching RA-ld and including T-CRNTI. 
The CRC is calculated in such a way, it will 
result in CRC error on UE side 


<— 


Random Access Response 


1 




4 


Check: does the UE transmit a HARQ 
ACK/NACK? 


— > 


HARQ ACK/NACK 


1 


F 


5 


Within ra-ResponseWindowSize from step 2, 
the SS re-transmits Random Access 
Response in step 3. The CRC is calculated in 
such a way, it will result in CRC pass on UE 
side. 


<— 


Random Access Response 


2 




6 


Check: does the UE transmit a HARQ ACK? 


-> 


HARQ ACK 


1 


F 


7 


The UE transmits a IVIAC PDU containing an 
RRCConnectionRequest message. 


— > 


MAC PDU 


- 


- 


8 


The SS transmits a valid MAC PDU containing 
RRCConnectionSetup, and including 'UE 
Contention Resolution Identity' IVIAC control 
element with not matching 'Contention 
Resolution Identity'. 


<— 


MAC PDU 






9 


Check: does the UE transmit a HARQ NACK? 


— > 


HARQ NACK 


2 


F 


10 


The UE transmits Preamble on PRACH 


— > 


PRACH Preamble 


- 


- 


11 


The SS transmits Random Access Response 
with matching RA-ld and including T-CRNTI. 


<— 


Random Access Response 


- 


- 


12 


The UE transmits a MAC PDU containing an 
RRCConnectionRequest message. 


— > 


MAC PDU 


- 


- 


13 


The SS transmits a valid MAC PDU containing 
RRCConnectionSetup, and including 'UE 
Contention Resolution Identity' MAC control 
element with matching 'Contention Resolution 
Identity'. The CRC is calculated in such a way 
that it will result in CRC error on UE side 


<— 


MAC PDU 






14 


Check: Does UE transmit a HARQ NACK? 


— > 


HARQ NACK 


3 


F 


15 


Within mac-ContentionResolutionTimer time 
from step 12, the SS transmits the same MAC 
PDU like in step 13, but the CRC is calculated 
in such a way that it will result in CRC pass on 
UEside 


<— 


MAC PDU 






16 


Check: does the UE transmit a HARQ ACK? 


-> 


HARQ NACK 


4 


P 


17 


The UE transmits a MAC PDU containing an 
RRCConnectionSetupComplete message 
indicating acceptance of 
RRCConnectionSetup message 


— > 


MAC PDU 







Note: It is not clear from core spec if the UE transmits a NACK or not after step 10. 
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7.1 .3.5.3.3 Specific message contents 

Table 7.1.2.4.3.3-1 : SystemlnformationBlockType2 (all steps, table 7.1.2.4.3.2-1) 



Derivation path: 36.508 table 4.4.3.3-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlocl<Type2 ::= SEQUENCE { 
radioResourceConfigCommon SEQUENCE { 
rach-Configuration SEQUENCE { 
ra-Supervisionlnformation SEQUENCE { 
preamblelransMax 
mac-ContentionResolutionTimer 
} 


n3 
sf64 


Max Value 
Max Value 




} 

prach-Configuration SEQUENCE { 
prach-Configlnfo SEQUENCE { 
prach-Configurationlndex 


1 


As per table 5.7.1 - 
2 of 25.211, this 
results in PRACH 
preamble 
transmission start 
in even frame 
numbers and sub- 




} 




frame number 4 




I 
} 
ue-TimersAndConstants SEQUENCE{ 

t300 

} 
} 


ms2000 


T300 





7.1.3.6 



Correct HARQ process handling [BCCH] 



7.1.3.6.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_Idle state} 
ensure that { 

when { UE receives a MAC PDU addressed to S-RNTi} 

then { UE does not send any ACK/NACK for the corresponding dedicated HARQ process} 



7.1.3.6.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.3.2.1 & 
5.3.2.2. 

[TS 36.321, clause 5.3.2.1] 

There is one HARQ entity at the UE which maintains a number of parallel HARQ processes. Each HARQ process is 
associated with a HARQ process identifier. The HARQ entity directs HARQ information and associated TBs received 
on the DL-SCH to the corresponding HARQ processes (see subclause 5.3.2.2). 

The number of DL HARQ processes and soft buffers are specified in [5], subclause 5.1.4.1.2. 

When the physical layer is configured for spatial multiplexing [2], one or two TBs are expected per subframe. 
Otherwise, one TB is expected per subframe. 

The UE shall: 

If a downlink assignment has been indicated for this TTI: 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 83 ETSI TS 136 523-1 V8.0.1 (2009-01) 

allocate the TBs received from the physical layer and the associated HARQ information to the HARQ 
processes indicated by the associated HARQ information. 

If a downlink assignment has been indicated for the broadcast HARQ process: 

allocate the received TB to the broadcast HARQ process. 

NOTE: In case of BCCH a dedicated broadcast HARQ process is used. [TS 36.321, clause 5.3.2.2] 

For each received TB and associated HARQ information, the HARQ process shall: 

if the NDI, when provided, has been toggled compared to the value of the previous received transmission for this 
HARQ process; or 

if the HARQ process is equal to the broadcast process and the physical layer indicates a new transmission; or 

if this is the very first received transmission for this HARQ process: 

replace the data currently in the soft buffer for this HARQ process with the received data. 

if the data has not yet been successfully decoded: 

combine the received data with the data currently in the soft buffer for this HARQ process. 

if the TB size is different from the last valid TB size signalled for this HARQ process: 

the UE may replace the data currently in the soft buffer for this HARQ process with the received data, 
attempt to decode the data in the soft buffer; 
if the data in the soft buffer was successfully decoded: 

if the HARQ process is equal to the broadcast process, deliver the decoded MAC PDU to RRC. 

else, deliver the decoded MAC PDU to the disassembly and demultiplexing entity. 

generate a positive acknowledgement (ACK) of the data in this HARQ process, 
else: 

generate a negative acknowledgement (NACK) of the data in this HARQ process. 

if the HARQ process is associated with a transmission indicated with a Temporary C-RNTI and a UE the 
Contention Resolution Identity match is not indicated successful (see subclause 5.1.5); or 

if the HARQ process is equal to the broadcast process; or 

if there is a measurement gap at the time of the transmission of the HARQ feedback: 

do not indicate the generated positive or negative acknowledgement to the physical layer, 
else: 

indicate the generated positive or negative acknowledgement to the physical layer. 

7.1.3.6.3 Test description 

7.1.3.6.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

UE: 
None. 
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Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 



7.1.3.6.3.2 



Test procedure sequence 



Table 7.1.3.6.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 




U-S 


lUlessage 


1 


The SS transmits an updated system 
information with S-RNTI addressed in L1/L2 
header. CRC is calculated in such a way, it will 
result in CRC fail on UE side. Dedicated 
HARQ process for broadcast is used. 










2 


Check: Does the UE transmit a HARQ NACK ? 


-> 


HARQ NACK 


1 


F 


3 


Wait for 1 seconds for UE to attempt to read 
the modified system information. 


- 


- 


- 


- 


4 


The SS transmits a Paging message including 
a matched identity. 


<— 


- 






45 


Check: does the UE transmits a IVIAC PDU 
containing an RRCConnectionRequest 
message? 


— > 


MAC PDU 


1 


P 


6 


The SS transmits an updated system 
information with S-RNTI addressed in L1/L2 
header. CRC is calculated in such a way, it will 
result in CRC fail on UE side. Dedicated 
HARQ process for broadcast is used. 










7 


Check: does the UE transmit an ACK? 


-> 


HARQ ACK 


1 


F 


8 


Wait for 1 seconds for UE to read the 
modified system information. 


- 


- 


- 


- 


9 


The SS transmits a Paging message including 
a matched identity. 


<— 


- 


- 


- 


10 


Check: does the UE transmit a IVIAC PDU 
containing an RRCConnectionRequest 
message, using PRACH resources as in new 
SI. 


— > 


MAC PDU 


1 


P 



7.1.3.6.3.3 



Specific message contents 



Table 7.1 .3.6.3.3-1 : SystemlnformationBlockType2 (steps 1 and 6 of table 7.1 .3.6.3.2-1) 



Derivation path: 36.508 table 4.4.3.3-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 








radioResourceConfigCommon SEQUENCE { 








prach-Configuration SEQUENCE { 








rootSequencelndex 


Value different than 


As portable 5.7.1- 






default 


2 of 25.211, this 
results in PRACH 
preamble 
transmission start 
in even frame 
numbers and sub- 




} 
} 
} 




frame number 4 
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7.1.3.7 



MAC-Padding 



7.1.3.7.1 



Test Purpose (TP) 



(1) 



with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 
when{ UE is receiving RLC PDUs in MAC PDUs with padding greater than 2 bytes } 
then { UE acknowledge reception of the RLC PDUs } 
} 

(2) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when { UE is receiving RLC PDUs in MAC PDUs with padding less than 2 bytes } 
then { UE acknowledge reception of the RLC PDUs } 
} 

(3) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 
when { SS is tranmitting a MAC control Timing Advance PDU with padding less than 2 bytes and no 
Data MAC PDU sub-headers followed by tranmitting a RLC PDU using the new Timing Advance value } 
then { UE acknowledge reception of the RLC PDU } 
} 

7.1.3.7.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 6.1.2. 

[TS 36.321 clause 6.1.2] 



Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required but cannot be 
achieved by padding at the end of the MAC PDU. 

When single-byte or two-byte padding is required but cannot be achieved by padding at the end of the MAC PDU, one 
or two MAC PDU sub-headers corresponding to padding are inserted before the first MAC PDU sub header 
corresponding to a MAC SDU; or if such sub header is not present, before the last MAC PDU sub header corresponding 
to a MAC control element. 

A maximum of one MAC PDU can be transmitted per TB per UE. 



MAC header 



R/R/E/LCID R/R/E/LCID[/F/L] R/R/E/LCID/F/L R/R/E/LCID/F/L 
sub-header sub-header sub-header sub-header 



R/R/E/LCID/F/L R/R/E/LCID padding 
sub-header sub-header 



MAC Control 
element 1 



MAC Control 
element 2 



MAC SDU 



MAC SDU ^f^|"9 

(opt) 



-MAC payload- 



Figure 6.1.2-3: MAC PDU consisting of lUIAC header, lUIAC control elements, MAC SDUs and padding 
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Test description 
Pre-test conditions 



7.1.3.7.3 




7.1.3.7.3.1 




System Simu 


ilator 


- Cell 1 




UE: 




None. 





Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 
The UL RLC SDU size is set to not return any data. 
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7.1.3.7.3.2 



Test procedure sequence 



Table 7.1.3.7.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




1 


The SS transmits a MAC PDU containing a 
RLC SDU in an AIVID PDU witli polling field 'P' 
set to '1 '. The MAC SDU payload is set 1 0- 
bytes smaller than the TB size allocated in the 
DL Assignment minus AMD PDU and MAC 
headers. 


<— 


MAC PDU(AMD PDU, padding) 






2 


Check: Does the UE transmit an RLC STATUS 
PDU with ACK SN field equal to 1 ? 


— > 


RLC STATUS PDU (ACK_SN 'n') 


1 


P 


3 


The SS transmits a MAC PDU containing a 
RLC SDU in an AMD PDU. The MAC SDU 
payload is set to 1 -byte smaller than the TB 
size allocated in the DL Assignment minus 
AMD PDU and MAC headers. SS adds a 1 
byte padding by inserting a MAC PDU sub- 
header before first Data MAC PDU sub- 
header. 


<- 


MACPDU(AMD PDU, one byte 
padding) 






4 


Check: does the UE transmit an RLC STATUS 
PDU with ACK SN field equal to 2? 


— > 


MAC PDU(RLC STATUS PDU 
(ACK SN =2) 


2 


P 


5 


The SS sets the downlink assignment for TBS 
of '16-bits' 


- 


- 


- 


- 


6 


The SS transmits a Timing Advance without 
any additional padding. Start Timer_1 = Time 
Alignment timer value. 


<— 


MAC Control PDU(Timing 
Advance) 






7 


The SS sets the downlink assignment for TBS 
of '24-bits' 


- 


- 


- 


- 


8 


The SS waits a time period equal to 0.5 of 
Timer_1 value and configures a MAC PDU that 
consists of only a Control MAC PDU sub 
header {8-bits). Transmit another Timing 
Advance MAC PDU (8-bits) which leaves 1- 
byte padding. The SS does not transmit any 
subsequent timing alignment. Restart Timer_1 
= Time Alignment timer value 


<— 


MAC Control(Timing Advance) + 
1-byte padding 






9 


The SS waits a time period equal to 0.7 of 
Timer_1 and then transmits MAC PDU 
containing one RLC SDU in an AMD PDU with 
polling field 'P' set to '1'. 


<— 


MAC PDU(AMD PDU (SN=2, P=1) 






10 


Check: does the UE transmit an RLC STATUS 
PDU acknowledging the reception of the RLC 
PDU in step 9? 


— > 


MAC PDU(RLC STATUS PDU 
(ACK_SN =3) 


3 


P 



7.1.3.7.3.3 
None. 



Specific Message Contents 



7.1.4 UL-SCH Data Transfer 



7.1.4.1 



Correct handling of UL assignment / dynamic case 



7.1.4.1.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives for a TTI an uplink grant with valid C-RNTi} 

then { UE transmits data and associated HARQ information to the HARQ entity for this TTI 
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7.1.4.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clause 5.4.1. 

[TS 36.321, clause 5.4.1] 

In order to transmit on the UL-SCH the UE must have a valid uplink grant (except for non-adaptive HARQ 
retransmissions) which it may receive dynamically on the PDCCH or in a Random Access Response or which may be 
configured semi-persistently. To perform requested transmissions, the MAC layer receives HARQ information from 
lower layers. 

When the UE has a C-RNTl, Semi-Persistent Scheduling C-RNTl, or Temporary C-RNTl, the UE shall for each TTI: 

if an uplink grant for this TTI has been received on the PDCCH for the UE's C-RNTl or Temporary C-RNTl; or 

if an uplink grant for this TTI has been received in a Random Access Response: 

deliver the uplink grant and the associated HARQ information to the HARQ entity for this TTI. 

else, if an uplink grant for this TTI has been received on the PDCCH for the UE's Semi-Persistent C-RNTI: 

if the NDI in the received HARQ information is 1 : 

consider the NDI not to have been toggled; 

indicate a valid uplink grant and the associated HARQ information to the HARQ entity for this TTI. 

NOTE: The period of configured uplink grants is expressed in TTIs. 

NOTE: If the UE receives both a grant for its RA-RNTI and a grant for its C-RNTI, the UE may choose to 
continue with either the grant for its RA-RNTl or the grant for its C-RNTI. 



7.1.4.1.3 


Test description 


7.1.4.1.3.1 


Pre-test conditions 


System Simulator 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.1.4.1.3.2 



Test procedure sequence 



Table 7.1.4.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


2 


SS transmits a MAC PDU including a RLC 
SDU 


<— 


MAC PDU 


1 


- 


3 


The SS responds to any scheduling grants by 
sending an UL Grant, allowing the UE to return 
the RLC SDU as received in step 2, on 
PDCCH with the C-RNTI as assigned to the 
UE. 


<— 


(UL Grant (C-RNTI)) 






4 


Check: Does the UE transmit associated 
HARQ information with RV=0? 


— > 


HARQ ACK 


1 


P 


5 


Check: Does the UE transmit a IVIAC PDU? 


— > 


MAC PDU 


1 


P 


6 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


7 


SS transmits a MAC PDU containing a RLC 
SDU 


<— 


MAC PDU 


- 


- 


8 


The SS responds to any scheduling grants by 
sending an UL Grant, allowing the UE to return 
the RLC SDU as received in step 7, on 
PDCCH, but with a C-RNTI different from the 
C-RNTI assigned to the UE. 


<— 


(UL Grant (unknown C-RNTI)) 






9 


Check: Does the UE transmit associated 
HARQ information with RV=0? 


— > 


HARQ ACK 


1 


P 


10 


Check: Does the UE transmit any MAC PDU? 


- 


- 


1 


F 



7.1.4.1.3.3 
None. 



Specific message contents. 



7.1 .4.2 Correct handling of UL assignment / semi persistent case 

7.1.4.2.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_Connected state with DRB established} 
ensure that { 

when { UE receives a UL grant addressed to its SPS-CRNTI in sub-frame y and with NDI set as } 
then { UE starts transmitting UL MAC PDU in sub frames y+4+n* [semiPersistSchedlntervalUL] where 
'n' is an integer [>=0] } 
} 

(2) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored UL SPS grant to transmit MAC 
PDU at subframe y+4+n* [semiPersistSchedlntervalUL] } 
ensure that { 

when { UE receives a UL grant addressed to its SPS-CRNTI in sub-frame P and with NDI set as 0, 
where p!= y+n* [semiPersistSchedlntervalUL] } 

then { UE starts transmiting UL MAC PDU in sub frames p+4+n* [semiPersistSchedlntervalUL] and 
stops transmiting UL MAC PDU at sub frames y+4+n* [semiPersistSchedlntervalUL] where 'n' is an integer 
[> = 0] } 

(3) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored UL SPS grant to transmit MAC 
PDU at subframe y+4+n* [semiPersistSchedlntervalUL] } 
ensure that { 

when { UE receives a UL grant [for retransmission] addressed to its SPS-CRNTI in sub-frame z and 
with NDI set as 1, for the corresponding HARQ Process, where z!= y+n* [semiPersistSchedlntervalUL] } 
then { UE re-tranmis MAC PDU in sub frame z+4 as per the new grant for SPS-CRNTI } 
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(4) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored UL SPS grant to receive MAC 
PDU at subframe z+4+n* [semiPersistSchedlntervalUL] } 
ensure that { 

when { UE receives a UL grant addressed to its CRNTI in sub- frame p, such that in subframe p+4= 
z+4+n* [semiPersistSchedlntervalUL] } 

then { UE transmits MAC PDU in sub frame p+4 as per grant addresed to its C-RNTI } 

(5) 

with { UE in E-UTRA RRC_Connected state with DRB established and stored UL SPS grant to receive MAC 
PDU at subframe z+4+n* [semiPersistSchedlntervalUL] } 
ensure that { 

when { UE receives a RRCConnectionReconf iguration including the mobilityControlInformation and 
hence resulting in SPS grant deactivation} 

then { UE stops transmiting UL MAC 
PDU' s as per stored SPS grant in sub frame z+4+n* [semiPersistSchedlntervalUL] } 
} 

Editors note: SPS Grant deactivation is not very clear 

7.1.4.2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321 clause 5.4.1 and 
36.331 clause 5.3.10.5. 

[TS 36.321, clause 5.4.1] 

In order to transmit on the UL-SCH the UE must have a valid uplink grant (except for non-adaptive HARQ 
retransmissions) which it may receive dynamically on the PDCCH or in a Random Access Response or which may be 
configured semi-persistently. To perform requested transmissions, the MAC layer receives HARQ information from 
lower layers. 

When the UE has a C-RNTI, Semi-Persistent Scheduling C-RNTI, or Temporary C-RNTI, the UE shall for each TTI: 

if an uplink grant for this TTI has been received on the PDCCH for the UE's C-RNTI or Temporary C-RNTI; or 

if an uplink grant for this TTI has been received in a Random Access Response: 

deliver the uplink grant and the associated HARQ information to the HARQ entity for this TTI. 

else, if an uplink grant for this TTI has been received on the PDCCH for the UE's Semi-Persistent C-RNTI: 

if the NDI in the received HARQ information is 1 : 

consider the NDI not to have been toggled; 

indicate a valid uplink grant and the associated HARQ information to the HARQ entity for this TTI. 

else if the NDI in the received HARQ information is 0: 

store the uplink grant and the associated HARQ information as configured uplink grant; 

initialise (if not active) or re-initialise (if already active) the configured uplink grant to start in this TTI 
and to recur with the periodicity configured via RRC; 

consider the NDI bit to have been toggled; 

indicate a configured uplink grant, valid for new transmission, and the associated HARQ information to 
the HARQ entity for this TTI. 

- else, if [PDCCH condition for deactivation of SPS] : 

clear the configured uplink grant (if any). 

else, if an uplink grant for this TTI has been configured: 

consider the NDI bit to have been toggled; 

deliver the configured uplink grant, and the associated HARQ information to the HARQ entity for this TTI. 
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NOTE: The period of configured uplink grants is expressed in TTIs. 

NOTE: If the UE receives both a grant for its RA-RNTI and a grant for its C-RNTI, the UE may choose to 
continue with either the grant for its RA-RNTI or the grant for its C-RNTI. 

[TS 36.331, clause 5.3.10.5] 

Authors Note: Is this allowed? 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 



7.1.4.2.3 


Test description 


7.1.4.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 

The loop back size is set in such a way that one RLC SDU in DL shall result in 1 RLC SDU's in UL of same 
size. 

Following specific parameters in table 7.1.4.2.3.1-1 are allocated to the UE during preamble. 

Table 7.1.4.2.3.1-1 : specific Parameters in RRCConnectionReconfiguration 



Parameter 


Value 


semiPersistSchedlntervalUL 


sf160 


Semi-Persistent Scheduling C-RNTI 


FFS* 



Editors Note: It is not yet clear how the SPS C-RNTI is assigned to UE. 
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7.1.4.2.3.2 



Test procedure sequence 



Table 7.1.4.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a DL MAC PDU containing 9 
RLC SOU'S 


<— 


MAC PDU 


- 


- 


2 


The UE transmits a Scheduling Request, 
indicating that loop back PDUs are ready for 
transmission in UL RLC 


— > 


(SR) 






3 


The SS transmits an UL Grant using UE's SPS 
C-RNTI in sub frame 'Y', NDI=0, allowing the 
UE to transmit one loop back PDU per MAC 
PDU. 


<— 


(UL SPS Grant) 






4 


Check: Does the UE transmit a MAC PDU in 
sub frame 'Y+4'? 


— > 


MAC PDU 


1 


P 


5 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


- 




6 


Check: does The UE transmit a MAC PDU in 
sub frame 
'Y+4+XsemiPersistSchedlntervalUL'? 


— > 


MAC PDU 


1 


P 


7 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


- 


- 


8 


The SS Transmits an UL Grant using UE's 
SPS C-RNTI in sub frame 'P', NDI=0,where 
Y+X<P< Y+2X, and allowing the UE to 
transmit two loop back PDUs per MAC PDU. 


<— 


(UL SPS Grant) 






9 


Check: Does the UE transmit a MAC PDU in 
sub frame 'P+4' as per grant in step 8? 


— > 


MAC PDU 


2 


P 


10 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


- 


- 


11 


Check: does the UE transmit a MAC PDU in 
sub frame 'Y+4+2X'? 


— > 


MAC PDU 


2 


F 


12 


Check: Does the UE transmit a MAC PDU in 
sub frame 'P+ 

4+X semiPersistSchedlntervalUU as per grant 
in step 8? 


— > 


MAC PDU 


2,3 


P 


13 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


- 


- 


14 


The SS Transmits an UL Grant using UE's 
SPS C-RNTI in sub frame 'Z', NDI=1 , where P 
< Z <P-i-1X; the UL HARQ process is the same 
as in step 12 


<— 


(UL SPS Grant) 






15 


Check: Does the UE transmit in sub frame 
'Z+4' a MAC PDU as in step 12? 


— > 


MAC PDU 


3 


P 


16 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


3 




17 


Check: Does the UE transmit a MAC PDU in 
sub frame 

'P+4+2X semiPersistSchedlntervalUL' as per 
grant in step 8? 


— > 


MAC PDU 


1 


P 


18 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


- 


- 


19 


The SS Transmits a UL Grant using UE's C- 

RNTI in sub frame 

'P+3X semiPersistSchedlntervalUL'; allowing 

UE to transmit MAC PDU containing one RLC 

SDU 


<— 


(DL Grant) 






20 


Check: Does the UE transmit a MAC PDU in 
sub frame 

'P+4+3X semiPersistSchedlntervalUL' as per 
grant in step 19? 


— > 


MAC PDU 


4 


P 


21 


The SS transmits a HARQ ACK 


<— 


HARQ ACK 


- 


- 


22 


SS Transmits RRCConnectionReconfiguration 
including the mobilityControllnformation 


- 


- 


- 


- 


23 


The UE transmits 
RRCConnectionReconfigurationComplete 


- 


- 


- 


- 


24 


The SS transmits DL MAC PDU containing 1 
RLC SDU's 


<— 


MAC PDU 


- 


- 


25 


The UE transmits Scheduling request, 
indicating loop back PDU's ready for 
transmission in UL RLC 


— > 


(SR) 
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26 


Check :does the UE transmit a MAC PDU in 
sub frame 

'Y+4+nX semiPersistSchedlntervalUL'as per 
grant in step 8? 


— > 


MAC PDU 


5 


F 


27 


SS transmits an UL Grant 


<— 


(UL Grant) 


- 


- 


28 


The UE transmits MAC PDU as per grant in 
step 27. 


— > 


MAC PDU 


- 


- 



Note 1 : Steps 27 and 28 are executed to bring UE in stable state. 



7.1.4.2.3.3 
None. 



Specific message contents 



7.1.4.3 



Logical channel prioritization handling 



Editor's note: This test case is not based on 36.321 v8.3.0. 



7.1.4.3.1 



Test Purpose (TP) 



(1) 

with {UE in E-UTRA RRC_CONNECTED state} 
ensure that { 

when { sending data on the uplink } 
then { UE serves the logical channels according to their priority and configured PBR } 

} 

7.1.4.3.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clauses 5.4.3.1. 

[TS 36.323, clause 5.4.3.1] 

The Logical Channel Prioritization procedure is applied when a new transmission is performed. 

RRC can control the scheduling of uplink data by giving each logical channel a priority where increasing priority values 
indicate lower priority levels. In addition, each logical channel is given a Prioritized Bit Rate (PBR). 

The UE shall perform the following Logical Channel Prioritization procedure when a new transmission is performed: 

The UE shall allocate resources to the logical channels in the following sequence: 

all the logical channels are allocated resources in a decreasing priority order up to a value such that on 
average, the served data rate for radio bearers that have data for transmission equals the configured PBR for 
the radio bearer. If the PBR of a radio bearer is set to "infinity", the UE shall allocate resources for all the 
data that is available for transmission on the radio bearer before meeting the PBR of the lower priority radio 
bearer(s); 

if any resources remain, all the logical channels are served in a strict decreasing priority order until either the 
data for that logical channel or the UL grant is exhausted, whichever comes first. 

The UE shall also follow the rules below during the scheduling procedures above: 

the UE should not segment an RLC SDU (or partially transmitted SDU or retransmitted RLC PDU) if the 
whole SDU (or partially transmitted SDU or retransmitted RLC PDU) fits into the remaining resources; 

if the UE segments an RLC SDU from the logical channel, it shall maximize the size of the segment to fill 
the grant as much as possible; 

the UE shall serve as much data as it can to fill the grant in general. However, if the remaining resources 
require the UE to segment an RLC SDU with size smaller than x bytes or smaller than the L2 header size 
(FES), the UE may use padding to fill the remaining resources instead of segmenting the RLC SDU and 
sending the segment. 

Logical channels configured with the same priority shall be served equally the by UE. 
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MAC control elements for BSR, with exception of Padding BSR, have higher priority than U-plane Logical Channels. 

At serving cell change, the first UL-DCCH MAC SDU to be transmitted in the new cell has higher priority than MAC 
control elements for BSR. 



Test description 
Pre-test conditions 



7.1.4.3.3 

7.1.4.3.3.1 

System Simulator: 
- Cell 1 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
3 DRBs are configured according to table 7.1.4.3.3.1-1. 



Table 7.1 .4.3.3.1-1: Priority and PBR settings 



DRB 



DRB1 
DRB2 
DRBS 



Priority 

1 
2 
3 



PBR 

8 kBytes/s 
1 6 kBytes/s 
32 kBytes/s 



7.1.4.3.3.2 



Test procedure sequence 



Table 7.1.4.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS sends N1 320-octet RLC SDUs on 
DRB1 , N2 320-octet RLC SDUs on DRB2, and 
N3 320-octet RLC SDUs on DRB3. 


<— 


RLC SDUs 








EXCEPTION: the steps 2 to 4 are run 4 times 
using the parameters specified for each run in 
table 7.1 .4.3.3.2-3. In addition, for each run, 
the step 2 is run in parallel with the behaviour 
specified in table 7.1.4.3.3.2-2. 










2 


For a duration of T2, the SS sends an UL grant 
of D octets every T1 . 


<— 


UL grants 


- 


- 


3 


Check: the total number of octets of the UL 
RLC SDUs received at the SS for each DRB 
as follows: 

- the total number of octets received for DRB1 
is D1 octets +/- 10% 

- the total number of octets received for DRB2 
is D2 octets +/- 1 0% 

- the total number of octets received for DRB3 
is D3 octets +/- 1 0% 






1 


P 


4 


The SS re-establish the RLC for each RB at 
the UE. 


- 


- 


- 


- 



Table 7.1.4.3.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The UE sends the RLC SDUs back to the SS. 


— > 


- 


- 


- 
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Table 7.1.4.3.3.2-3: Test parameter values 



Parameter 


First run 


Second run 


Third run 


Fourtli run 


N1 (SDUs) 


13 


13 


7 


104 


N2 (SDUs) 


25 


25 


50 


25 


N3 (SDUs) 


50 


50 


50 


50 


D (octets) 


1128 


568 


1128 


2280 


T1 (ms) 


20 


20 


20 


20 


T2 (ms) 


500 


500 


500 


500 


D1 (octets) 


4160 


4000 


2240 


33000 


D2 (octets) 


8000 


8000 


9960 


8000 


D3 (octets) 


16000 


2200 


16000 


16000 



Editor's note; the numbers above and the test procedure assume that the UE has a loopback buffer of at least 57280 
octets. 

7.1 .4.4 Correct Handling of MAC control information [ Scheduling Requests/ 

PUCCH] 

Editor's note: This test case is not based on 36.321 v8.3.0. 



7.1.4.4.1 



Test Purpose (TP) 



with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when { PUCCH Configured and UE has UL data in transmission buffer and UE has no UL-SCH resources 
available } 

then { the UE transmits a SR on PUCCH at every TTI until resources are granted } 

} 

7.1.4.4.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.4.4. 

[TS 36.321 clause 5.4.4] 

The Scheduling Request (SR) is for requesting UL-SCH resources. 

If an SR has been triggered, the UE shall for each TTI, until UL-SCH resources are granted for a new transmission: 

if no UL-SCH resources are available in this TTI: 

if a PUCCH is configured for the UE to send an SR in this TTI and if there is no measurement gap in this 
TTI, instruct the physical layer to signal the SR on PUCCH; 

if no PUCCH for SR is configured for the UE in any TTI, initiate a Random Access procedure (see subclause 
5.1). 

NOTE: A triggered SR is considered pending and is repeated until UL-SCH resources are granted for a new 
transmission. 



7.1.4.4.3 




7.1.4.4.3.1 




System Simi 


lator 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 
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Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 



7.1.4.4.3.2 



Test procedure sequence 



Table 7.1.4.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a IVIAC PDU containing 10 
IVIAC SDUs each containing a RLC SDU 


<— 


MAC PDU (containing 10 MAC 
SDUs) 








EXCEPTION: Step 2 shall be repeated for 20 
TTIs. Step 2 runs in parallel with behaviour in 
table 7.1.4.4.3.2-2. 










2 


Check: does the UE transmit a Scheduling 
Request on PUCCH at this TTI? (Note 1) 


— > 


(SR) 


1 


P 


3 


The SS transmits UL grant to allocate UL-SCH 
resources that are enough to transmit MAC 
PDU containing 10 MAC SDUs 


<— 


(UL Grant ) 






4 


Check: Does the UE transmit a MAC PDU 
containing 10 RLC PDUs? 


-> 


MAC PDU (containing 10 MAC 
SDUs) 


1 


P 


Note 1 : The UE repeats the scheduling requests as long there is data in the transmission buffer and there are no 
resources available to transmit it. 


Table 7.1.4.4.3.2-2: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Check: Does the UE transmit a MAC PDU? 


-> 


MAC PDU 


1 


F 



7.1.4.4.3.3 
None. 

7.1.4.5 

7.1.4.5.1 



Specific Message Contents 



Correct Handling of MAC control information [ Scheduling Requests/Random 
Access Procedure] 

Test Purpose (TP) 



with { UE is in E-UTRA RRC_CONNECTED state, no PUCCH for SR is configured } 
ensure that { 

when { UE receives a MAC PDU with a Timing Advance control elementand UL data in transmission 
buffer and no UL-SCH resources available } 

then { the UE initiates the random access procedure } 
} 

7.1.4.5.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321 , clause 5.4.4. 

[TS 36.321 clause 5.4.4] 

The Scheduling Request (SR) is for requesting UL-SCH resources. 

If an SR has been triggered, the UE shall for each TTI, until UL-SCH resources are granted for a new transmission: 

if no UL-SCH resources are available in this TTI: 

if a PUCCH is configured for the UE to send an SR in this TTI and if there is no measurement gap in this 
TTI, instruct the physical layer to signal the SR on PUCCH; 

if no PUCCH for SR is configured for the UE in any TTI, initiate a Random Access procedure (see subclause 
5.1). 
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NOTE: A triggered SR is considered pending and is repeated until UL-SCH resources are granted for a new 

transmission. 



7.1.4.5.3 


Test description 


7.1.4.5.3.1 


Pre-test conditions 


System Simulator 




- Cell 1 




UE 




None. 





Preamble 

- The UE is in state Loopback Activated (state 4) according to [18]. 



7.1.4.5.3.2 



Test procedure sequence 



Table 7.1.4.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a IVIAC PDU containing a 
IVIAC SDU and a Timing Advance MAC Control 
Element, but do not send any subsequent 
alignments. 


<— 


MAC PDU (Timing Advance 
Command, MAC SDU) 






- 


EXCEPTION: Step 2 runs in parallel with 
behaviour in table 7.1 .4.4.3.2-2 


- 


- 


- 


- 


2 


Check: does the UE transmit a preamble on 
PRACH?(Note1) 


— > 


(PRACH Preamble) 


1 


P 


4 


The SS transmits a Random Access Response 
including an UL grant to enable UE to transmit 
C-RNTI IVIAC Control Element and the RLC 
SDU as received in step 1 . 


<— 


Random Access Response 






5 


Check: does the UE transmit a IVIAC PDU 
including a C-RNTI MAC Control Element and 
a MAC SDU? (Note 2) 


-> 


MAC PDU (C-RNTI control 
element, MAC SDU) 


1 


P 


6 


The UE transmits a MAC PDU including a UE 
Contention Resolution control element) 


<— 


MAC PDU (UE Contention 
Resolution Identity) 


- 


- 


Note 1 When UL time alignment timer expires in the UE then "UL synchronization" is lost and the UE initiates a 

Random Access Procedure. 
Note 2 The UE transmission of the IVIAC PDU ensures that the random access procedure was successful. 



Table 7.1.4.5.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


UE may transmit a Scheduling Request before 
timing alignment timer expires. SS shall not 
respond to the Scheduling Grant. 


— > 


(SR) 







7.1.4.5.3.3 
None. 



Specific Message Contents 
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7.1 .4.6 Correct Handling of MAC control information [Buffer Status/ UL data arrives 

in the UE Tx buffer / Regular BSR] 

7.1 .4.6.1 Test Purpose (TP) 
(1) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when{ UL data arrives in the UE transmission buffer and the data belongs to a logical channel 
with higher priority than those for which data already existed in the UE transmission and more than 
one LCG has buffered data in a TTI } 

then { UE Reports a Long Buffer Status Reporting (BSR) } 
} 

(2) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when{ UL data arrives in the UE transmission buffer and the data belongs to a logical channel 
with higher priority than those for which data already existed in the UE transmission buffer and one 
LCG has buffered data in a TTI } 

then { UE Reports a Short Buffer Status Reporting (BSR) } 

} 

(3) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when { a Regular BSR has been triggered and UE has pending data for tranmission and UE has only 
resources to send either BSR report or data} 

then { UE transmits the pending BSR report} 

} 

(4) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when{ UE determines that a BSR has been triggered since last transmission while PUCCH is 
synchronised } 

then { UE transmits a scheduling request} 

} 

7.1.4.6.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.4.5, 6.1.2, 
6.1.3.1 and 6.2.1 and in TS 36.323 clause 4.5. 

[TS 36.321 clause 5.4.3.1] 



MAC control elements for BSR, with exception of Padding BSR, have higher priority than U-plane Logical Channels. 

[TS 36.321 clause 5.4.5] 

The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data in 
the UL buffers of the UE. 

A Buffer Status Report (BSR) shall be triggered if any of the following events occur: 

UL data arrives in the UE transmission buffer in the RLC entity or in the PDCP entity (the definition of what 
data shall be considered as available for transmission is specified in [3] and [4] respectively) and the data 
belongs to a logical channel with higher priority than those for which data already existed in the UE transmission 
buffer, in which case the BSR is referred below to as "Regular BSR"; 



For Regular and Periodic BSR: 

if only one LCG has data available for transmission in the TTI where the BSR is transmitted: report Short BSR; 
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else if more than one LCG has data available for transmission in the TTI where the BSR is transmitted: report 
Long BSR. 

If the Buffer Status reporting procedure determines that a BSR has been triggered since the last transmission of a BSR 
or this is the first time that a BSR is triggered: 

if the UE has UL resources allocated for new transmission for this TTI: 

instruct the Multiplexing and Assembly procedure to generate a BSR MAC control element; 

- restart the PERIODIC BSR TIMER. 

else if a Regular BSR has been triggered: 

a Scheduling Request shall be triggered. 

NOTE: Even if multiple events occur by the time a BSR can be transmitted, only one BSR will be included in the 
MAC PDU. 

A pending BSR shall be cancelled in case the UL grant can accommodate all pending data available for transmission 
but is not sufficient to additionally accommodate the BSR MAC control element. 

[TS 36.321 clause 6.1.2] 

MAC control elements are always placed before any MAC SDU. 

[TS 36.321 clause 6.1.3.1] 

Buffer Status Report (BSR) MAC control elements consist of either: 

Short BSR and Truncated BSR format: one LCG ID field and one corresponding BS field (figure 6.1.3.1-1); or 

Long BSR format: four Buffer Size fields, corresponding to LCG IDs #1 through #4 (figure 6.1.3.1-2). 

The BSR formats are identified by MAC PDU sub headers with LCIDs as specified in table 6.2.1.-1. 

The fields LCG ID and BS are defined as follow: 

LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is 
being reported. The length of the field is 2 bits; 

Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a 
logical channel group after the MAC PDU has been built. The amount of data is indicated in number of bytes. It 
shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of 
what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of 
the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits. 
The values taken by the Buffer Size field are shown in [Table 6.1.3.1-1]. 

I 1 1 1 1 1 1 1 1 

LCG ID Buffer Size Oct 1 



Figure 6.1.3.1-1: Short Buffer Status IVIAC control element 



Buffer Size #1 ^^^Z'n Oct 1 
Size #2 

Buffer Size #2 Buffer Size #3 Oct 2 

o-^^Z' Buffer Size #4 Oct 3 

bize #3 

Figure 6.1.3.1-2: Long Buffer Status MAC control element 
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Table 6.1.3.1-1 : Buffer size levels for BSR 



Index 


Buffer Size (BS) value [bytes] 


Index 


Buffer Size (BS) value [bytes] 





BS = 


32 


1 132 <BS<= 1326 


1 


0<BS<=10 


33 


1 326 <BS<= 1552 


2 


10<BS<= 12 


34 


1552 <BS<= 1817 


3 


12<BS<= 14 


35 


1817 <BS<= 2127 


4 


14<BS<= 17 


36 


2127 <BS<= 2490 


5 


17<BS<= 19 


37 


2490 <BS<= 2915 


6 


19<BS<=22 


38 


2915 <BS<= 3413 


7 


22 < BS <= 26 


39 


3413 <BS<= 3995 


8 


26 < BS <= 31 


40 


3995 < BS <= 4677 


9 


31 < BS <= 36 


41 


4677 < BS <= 5476 


10 


36 < BS <= 42 


42 


5476 < BS <= 641 1 


11 


42 < BS <= 49 


43 


641 1 < BS <= 7505 


12 


49 < BS <= 57 


44 


7505 < BS <= 8787 


13 


57 < BS <= 67 


45 


8787<BS<= 10287 


14 


67 < BS <= 78 


46 


10287<BS<= 12043 


15 


78 < BS <= 91 


47 


1 2043 <BS<= 14099 


16 


91 <BS<=107 


48 


1 4099 <BS<= 16507 


17 


107<BS<= 125 


49 


1 6507 <BS<= 19325 


18 


125<BS<= 146 


50 


1 9325 <BS<= 22624 


19 


146<BS<= 171 


51 


22624 < BS <= 26487 


20 


171 <BS<=200 


52 


26487 <BS<= 31 009 


21 


200 < BS <= 234 


53 


31009 <BS<= 36304 


22 


234 < BS <= 274 


54 


36304 < BS <= 42502 


23 


274 < BS <= 321 


55 


42502 < BS <= 49759 


24 


321 < BS <= 376 


56 


49759 < BS <= 58255 


25 


376 < BS <= 440 


57 


58255 < BS <= 68201 


26 


440<BS<=515 


58 


68201 < BS <= 79846 


27 


515<BS<=603 


59 


79846 < BS <= 93479 


28 


603 < BS <= 706 


60 


93479 <BS<= 109439 


29 


706 < BS <= 826 


61 


1 09439 <BS<= 128125 


30 


826 < BS <= 967 


62 


128125 <BS<= 150000 


31 


967 <BS<= 1132 


63 


BS> 150000 



[TS 36.321 clause 6.2.1, 6.2.1-2] 



Table 6.2.1-2 Values of LCID for UL-SCH 



Index 


LCID values 


00000 


CCCH 


00001-01010 


Identity of the logical channel 


01011-11001 


Reserved 


11010 


Power Headroom Report 


11011 


C-RNTI 


11100 


Truncated BSR 


11101 


Short BSR 


11110 


Long BSR 


11111 


Padding 



[TS 36.323 clause 4.5] 

For the purpose of MAC buffer status reporting, the UE shall consider the following as data available for transmission 
in the PDCP layer: 

For SDUs for which no PDU has been submitted to lower layers: 

the SDU itself, if the SDU has not yet been processed by PDCP, or 

the PDU (control or data) if the SDU has been processed by PDCP. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



101 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



7.1.4.6.3 


Test description 


7.1.4.6.3.1 


Pre-test conditions 


System Simulator : 




- Cell 1 




UE: 




None. 





Preamble : 

The UE is in state Loopback Activated (state 4) according to [18]. 
3 AM DRBS are configured with the following parameters: 

Table 7.1.4.6.1-1: Logical Channel Configuration Settings 



Parameter 


Value DRB1 


Value DRB1 


Value DRB1 


LogicalChannel-ldentity 


3 


4 


5 


Priority 


8 


7 


6 


prioritizedBitRate 


OkB/s 


OI<B/s 


OkB/s 


logicalChannelGroup 


2 (LOG ID#3) 


2 (LOG ID#3) 


1 (LCG ID#2) 
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7.1.4.6.3.2 



Test procedure sequence 



Table 7.1.4.6.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


2 


The SS transmits a MAC PDU containing two 
RLC SDUs of size 1 bytes on LC 3 


<— 


MAC PDU (2 RLC SDUs on LC 3) 


- 


- 


3 


Check: Does the UE transmit a scheduling 
request? 


— > 


(SR) 


4 


P 


4 


SS respond to the scheduling request in step 3 
by an UL Grant of 32 bits. (Note 1 ) 


<— 


(UL Grant, 32 bits) 


- 


- 


5 


Check: Does the UE transmit a Short BSR with 
'LCG ID' field set to '3' and 'Buffer size' field 
set to value '6' or bigger? (Note 2) 


— > 


MAC PDU (MAC Short BSR (LCG 
ID='3', Buffer Size='6' or bigger)) 


2,3 


P 


6 


The SS transmits a MAC PDU containing one 
RLC SDUs of size 1 bytes on LC 4 


<— 


MAC PDU (1 RLC SDUs on LC 4) 


- 


- 


7 


Check: Does the UE transmit a scheduling 
request? 


— > 


(SR) 


4 


P 


8 


SS respond to the scheduling request in step 7 
by an UL Grant of 32 bits. (Note 1 ) 


<— 


(UL Grant, 32 bits) 


- 


- 


9 


Check: Does the UE transmit a Short BSR with 
'LCG ID' field set to '3' and 'Buffer size#1 ' field 
set to value '8' or bigger? (Note 2) 


— > 


MAC PDU (MAC Short BSR (LCG 
ID='3', Buffer Size='8' or bigger)) 


2,3 


P 


10 


The SS transmits a MAC PDU containing two 
RLC SDUs of size 2 bytes on LC 5 


<— 


MAC PDU (2 RLC SDUs on LC 5) 


- 


- 


11 


Check: Does the UE transmit a scheduling 
request? 


— > 


(SR) 


4 


P 


12 


SS respond to the scheduling request in step 
1 1 by one UL Grant of 32 bits. (Note 2) 


<— 


(UL Grant, 32 bits) 


- 


- 


13 


Check: Does the UE transmit a Long BSR with 
'Buffer size#2' field set to value '6', 'Buffer 
size#3' field set to value '8' or bigger? (Note 2) 


— > 


MAC PDU (MAC Long BSR 
(Buffer size#2='6' or bigger, Buffer 
size#3='8' or bigger) 


1,3 


P 


Note 1 32 bits enables UE to transmit a MAC PDU with a MAC BSR header and a Short BSR (1 bytes) or a Long 

BSR (3 byte). 
Note 2 UE triggers a Short BSR of type "Regular BSR" to report buffer status for one LCG for that III. The UE 

should not send any of the received RLC SDUs (segmented) due to Regular BSR has higher priority than 

U-plane logical channels. 
Note 3 UE triggers and transmit a Long BSR of type "Regular BSR". The UL grant would be enough for UE to 

transmit one RLC SDU as received in step 8, but Regular BSR has higher priority than U-plane logical 

channels. 



7.1.4.6.3.3 
None. 



Specific Message Contents 



7.1 .4.7 Correct Handling of MAC control information [ Buffer Status/ UL resources 

are allocated/ Padding BSR] 



Editor's note: This test case is not based on 36.321 v8.3.0. 



7.1.4.7.1 



Test Purpose (TP) 



(1) 

with {UE in E-UTRA RRC_CONNECTED state = 
ensure that { 

when { UE transmits a MAC PDU and the number of padding bits are larger than the Size of a Short 
BSR plus its subheader, but less than the size of a Long BSR plus its subheader and the UE has 
buffered data from more than one LCG in the TTI where the BSR is transmitted } 
then { UE Reports a Truncated BSR with LCG containing highest LC priority } 
} 



ETSI 



3GPP TS 36.523-1 version 8.0.1 Release 8 103 ETSI TS 136 523-1 V8.0.1 (2009-01) 

(2) 

with {UE in E-UTRA RRC_CONNECTED state) 
ensure that { 

when { UE transmits a MAC PDU and the number of padding bits are larger than the Size of a Short 
BSR plus its subheader, but less than the size of a Long BSR plus its subheader and the UE has 
buffered data for only one LCG in the TTI where the BSR is transmitted } 
then { UE Reports a Short BSR indicating the LCG with buffered data} 
} 

(3) 

with {UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when{ UE transmits a MAC PDU and the number of padding bits are larger than the Size of a Long BSR 
plus its subheader } 

then { UE Reports a long BSR } 
} 

7.1.4.7.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.4.5, 6.1.2, 
6.1.3.1 and 6.2.1 and in TS 36.323 V8.2.1 clause 4.5. 

[[TS 36.321 clause 5.4.3.1] 



MAC control elements for BSR, with exception of Padding BSR, have higher priority than U-plane Logical Channels. 

TS 36.321 clause 5.4.5] 

The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data in 
the UL buffers of the UE. 

A Buffer Status Report (BSR) shall be triggered if any of the following events occur: 



UL resources are allocated and number of padding bits is equal to or larger than the size of the Buffer Status 
Report MAC control element, in which case the BSR is referred below to as "Padding BSR"; 



For padding BSR: 

if the number of padding bits is equal to or larger than the size of the Short BSR plus its sub header but smaller 
than the size of the Long BSR plus its sub header: 

if more than one LCG has buffered data in the TTI where the BSR is transmitted: report Truncated BSR of the 
LCG with the highest priority logical channel with data available for transmission; 

else report Short BSR. 

else if the number of padding bits is equal to or larger than the size of the Long BSR plus its sub header, report 
Long BSR. 

If the Buffer Status reporting procedure determines that a BSR has been triggered since the last transmission of a BSR 
or this is the first time that a BSR is triggered: 

if the UE has UL resources allocated for new transmission for this TTI: 

instruct the Multiplexing and Assembly procedure to generate a BSR MAC control element; 

- restart the PERIODIC BSR TIMER. 

else if a Regular BSR has been triggered: 
a Scheduling Request shall be triggered. 
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NOTE: Even if multiple events occur by the time a BSR can be transmitted, only one BSR will be included in the 
MAC PDU. 

A pending BSR shall be cancelled in case the UL grant can accommodate all pending data available for transmission 
but is not sufficient to additionally accommodate the BSR MAC control element. 

[TS 36.321 clause 6.1.2] 

MAC control elements are always placed before any MAC SDU. 

[TS 36.321 clause 6.1.3.1] 

Buffer Status Report (BSR) MAC control elements consist of either: 

Short BSR and Truncated BSR format: one LCG ID field and one corresponding BS field (figure 6.1.3.1-1); or 
Long BSR format: four Buffer Size fields, corresponding to LCG IDs #1 through #4 (figure 6.1.3.1-2). 

The BSR formats are identified by MAC PDU sub headers with LCIDs as specified in table 6.2.1.-1. 

The fields LCG ID and BS are defined as follow: 

LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is 
being reported. The length of the field is 2 bits; 

Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a 
logical channel group after the MAC PDU has been built. The amount of data is indicated in number of bytes. It 
shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of 
what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of 
the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits. 
The values taken by the Buffer Size field are shown in [Table 6.1.3.1-1]. 



LCG ID 



Buffer Size 



Oct1 



Figure 6.1.3.1-1 : Short Buffer Status IVIAC control element 



Buffer Size #1 



Buffer 



Buffer 
Size #3 



Buffer Size #4 



Oct1 



Size #2 

Buffer Size #2 Buffer Size #3 Oct 2 



Oct 3 



Figure 6.1.3.1-2: Long Buffer Status MAC control element 

[TS 36.321 clause 6.2.1, 6.2.1-2] 

Table 6.2.1-2 Values of LCID for UL-SCH 



Index 


LCID values 


00000 


CCCH 


00001-01010 


Identity of the logical channel 


01011-11001 


Reserved 


11010 


Power Headroom Report 


11011 


C-RNTI 


11100 


Truncated BSR 


11101 


Short BSR 


11110 


Long BSR 


11111 


Padding 



[TS 36.323 clause 4.5] 

For the purpose of MAC buffer status reporting, the UE shall consider the following as data available for transmission 
in the PDCP layer: 
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For SDUs for which no PDU has been submitted to lower layers: 

the SDU itself, if the SDU has not yet been processed by PDCP, or 
the PDU (control or data) if the SDU has been processed by PDCP. 

Test description 

Pre-test conditions 



7.1.4.7.3 




7.1.4.7.3.1 




System Simi 


ilator 


- Cell 1 




UE 




None. 





Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 

3 AM DRBS are configured with the parameters specified in table 7.1.4.7.1-1. 
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Table 7.1.4.7.1-1: Logical Channel Configuration Settings 



7.1.4.7.3.2 



Parameter 


DRB1 


DRB2 


LogicalChannel-ldentity 


3 


4 


Priority 


7 


6 


prloritizedBltRate 


Okbs 


OI<bs 


logicalChannelGroup 


2 (LOG ID#3) 


1 (LCG ID#2) 


periodicBSR-Tlmer 


infinity 



Test procedure sequence 



Table 7.1.4.7.3.2-1: IVIain behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplinl< grant. 


- 


- 


- 


- 


- 


EXCEPTION: Step 2 shall be repeated for 2 
times 


- 


- 


- 


- 


2 


The SS transmits a MAC PDU including an 
RLG SDU of size 12 bytes on logical channel 
4. 


<— 


MAC PDU (RLG SDU on LC 4) 






3 


The SS transmits a MAC PDU including an 
RLG SDU of size 12 bytes on logical channel 
3. 


<— 


MAC PDU (RLG SDU on LC 3) 






4 


SS waits [lOTTIs]. (Note 4) 


- 


- 


- 


- 


5 


The SS sends an uplinl< grant of size 32 bits. 
(Note 1) 


<— 


(UL grant) 


- 


- 


6 


The UE transmit a Long BSR report 


— > 


MAC PDU (Long BSR header 
(LCID='11110'), Long BSR) 


- 


- 


7 


The SS sends an uplinl< grant of size 136 bits. 
(Note 2) 


<— 


(UL grant) 


- 


- 


8 


Check: Does UE transmit a MAC PDU 
containing a RLG SDU and a Truncated BSR 
indicating pending data ('Buffer size' field > '0') 
for logicalChannelGroup 1 ('LCG ID' field set to 
'01')? 


— > 


MAC PDU (Truncated BSR 
header (LCID='1 11 00'), Short 
BSR(LCG ID ='01', Buffer 
size>'0'), RLG SDU) 


1 


P 


9 


SS waits [lOTTIs]. (Note 4) 


- 


- 


- 


- 


10 


The SS sends an uplink grant of size 136 bits 
(Note 2) 


<— 


(UL grant) 


- 


- 


11 


Check: Does UE transmit a MAC PDU 
containing a RLG SDU and with a Short BSR 
indicating pending data ('Buffer size' field > '0') 
for logicalChannelGroup 2 ('LCG ID' field 
='10')? 


— > 


MAC PDU (Short BSR 
header(LCID='11101'), Short 
BSR(LCG ID ='10',Buffersize>'0'), 
RLG SDU) 


2 


P 


12 


The SS transmits a MAC PDU including a RLG 
SDU of size 12 bytes on logical channel 3. 


<— 


MAC PDU (RLG SDU on LC 3) 


- 


- 


13 


SS waits [lOTTIs]. (Note 4) 


- 


- 


- 


- 


14 


The SS sends an uplink grant of size 152 bits. 
(Note 3) 


<— 


(UL grant) 


- 


- 


15 


Check: Does UE transmit a MAC PDU 
containing a RLG SDU and a Long? 


— > 


MAC PDU (Long BSR header 
(LCID='11110'), Long BSR), RLG 
SDU) 


3 


P 


Note 1 : SS transmit an UL grant of 32 bits {Itbs=0, Nprb=2, TS 36.213 Table 7.1 .7.2.1-1) to allow UE to transmit a 
Regular BSR triggered by the new data received logicalChannelGroup 2 and 1 in steps 2 and 3. This to 
enable testing of Padding BSR which has lower priority than Regular BSR. 

Note 2: UL grant of 1 36 bits (/res=9, NpRB=^ , TS 36.21 3 Table 7. 1 .7.2.1 -1 ) is chosen such that the MAG PDU 
padding bits will be equal to or larger than the size of Short/Truncated BSR and smaller than Long BSR. 
RLG SDL) size is 12 bytes, size of AMD PDU header is 2 bytes, size of MAC header is 2 bytes (1 byte for 
MAC SDU sub-header using R/R/E/LCID for last sub header and 1 byte for BSR sub-header) and size of 
Short BSR/Truncated BSR is one byte, i.e. setting UL grant to 17 bytes (136 bits) enable UE to include 
Short/Truncated BSR. 

Note 3: UL grant of 1 52 bits (/rss=9, NpRB=^ , TS 36.21 3 Table 7. 1 .7.2.1 -1 ) is chosen such that the MAC PDU 

padding bits will be equal to or larger than the size of Long BSR. RLG SDU size is 12 bytes, size of AMD 
PDU header is 2 bytes, size of MAC header is 2 bytes (1 byte for MAC SDU sub-header using R/R/E/LCID 
for last sub header and 1 byte for BSR sub-header) and size of Long BSR is 3 bytes, i.e. setting UL grant 
to 19 bytes (152 bits) enable UE to include padding Long BSR. 
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Note 4: The wait time is specified to ensure that the UE is ready to loop back the data when the grant is received. | 



7.1 .4.7.3.3 Specific Message Contents 

None. 

7.1 .4.8 Correct Handling of MAC control information [Buffer Status/ Periodic BSR 

Timer expires] 

7.1.4.8.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { PERIODIC BSR TIMER expires and more than one LCG has buffered data in a TTI } 
then { UE reports Long BSR } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { PERIODIC BSR TIMER expires and one LCG has buffered data in a TTI } 
then { UE reports Short BSR } 
} 

7.1.4.8.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.4.5, 6.1.2, 
6.1.3.1 and 6.2.1; TS 36.323 clause 4.5. 

[TS 36.321 clause 5.4.5] 

The Buffer Status reporting procedure is used to provide the serving eNB with information about the amount of data in 
the UL buffers of the UE. 

A Buffer Status Report (BSR) shall be triggered if any of the following events occur: 



- the PERIODIC BSR TIMER expires, in which case the BSR is referred below to as "Periodic BSR". 

For Regular and Periodic BSR: 

if only one LCG has data available for transmission in the TTI where the BSR is transmitted: report short BSR; 

else if more than one LCG has data available for transmission in the TTI where the BSR is transmitted: report 
long BSR. 

If the Buffer Status reporting procedure determines that a BSR has been triggered since the last transmission of a BSR 
or this is the first time that a BSR is triggered: 

if the UE has UL resources allocated for new transmission for this TTI: 

instruct the Multiplexing and Assembly procedure to generate a BSR MAC control element; 

- restart the PERIODIC BSR TIMER. 



NOTE: Even if multiple events occur by the time a BSR can be transmitted, only one BSR will be included in the 
MAC PDU. 
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A pending BSR shall be cancelled in case the UL grant can accommodate all pending data available for transmission 
but is not sufficient to accommodate the BSR MAC control element in addition. 

[TS 36.321 clause 6.1.2] 

MAC control elements are always placed before any MAC SDU. 

[TS 36.321 clause 6.1.3.1] 

Buffer Status Report (BSR) MAC control elements consist of either: 

Short BSR and Truncated BSR format: one LCG ID field and one corresponding BS field (figure 6.1.3.1-1); or 
Long BSR format: four Buffer Size fields, corresponding to LCG IDs #1 through #4 (figure 6.1.3.1-2). 

The BSR formats are identified by MAC PDU sub headers with LCIDs as specified in table 6.2.1.-1. 

The fields LCG ID and BS are defined as follow: 

LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is 
being reported. The length of the field is 2 bits; 

Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a 
logical channel group after the MAC PDU has been built. The amount of data is indicated in number of bytes. It 
shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of 
what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of 
the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits. 
The values taken by the Buffer Size field are shown in [Table 6.1.3.1-1]. 



LCG ID 



Buffer Size 



Oct1 



Figure 6.1.3.1-1: Short Buffer Status IVIAC control element 



Buffer Size #1 



Buffer 
Size #2 



Buffer Size #2 Buffer Size #3 

Buffer Size #4 



Buffer 
Size #3 



Oct1 
Oct 2 
Oct 3 



Figure 6.1.3.1-2: Long Buffer Status MAC control element 

[TS 36.321 clause 6.2.1, 6.2.1-2] 

Table 6.2.1-2 Values of LCID for UL-SCH 



Index 


LCID values 


00000 


CCCH 


00001-01010 


Identity of the logical channel 


01011-11001 


Reserved 


11010 


Power Headroom Report 


11011 


C-RNTI 


11100 


Truncated BSR 


11101 


Short BSR 


11110 


Long BSR 


11111 


Padding 



[TS 36.323 clause 4.5] 

For the purpose of MAC buffer status reporting, the UE shall consider the following as data available for transmission 
in the PDCP layer: 

For SDUs for which no PDU has been submitted to lower layers: 
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the SDU itself, if the SDU has not yet been processed by PDCP, or 
the PDU (control or data) if the SDU has been processed by PDCP. 



7.1.4.8.3 


Test description 


7.1.4.8.3.1 


Pre-test conditions 


System Simulator 




- Cell 1 




UE 




None. 





Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 

2 AM DRBS are configured with the parameters specified in table 7.1.4.8.1-1. 

Table 7.1.4.8.1-1: Logical Channel Configuration Settings 



Parameter 


DRB1 


DRB2 


LogicalChannel-ldentity 


3 


4 


priority 


7 


6 


prioritizedBitRate 


Okbs 


Okbs 


logicalChannelGroup 


2 


1 


periodicBSR-Timer 


10 SF 
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7.1.4.8.3.2 



Test procedure sequence 



Table 7.1.4.8.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


- 


EXCEPTION: Step 2 shall be repeated for 50 
times 


- 


- 


- 


- 


2 


The SS transmits a IVIAC PDU containing an 
RLC PDU on logical channel 4 (LCG ID 1) ), 
which contains an RLC SDU of size 14 bytes. 


<— 


MAC PDU (RLC SDU) 






3 


The SS sends an uplink grant of size 32 bits. 
(Note 3) 


<— 


(UL grant) 


- 


- 


4 


The UE transmit a Long BSR report 


— > 


MAC PDU (Long BSR) 






5 


The SS responds to any scheduling grants by 
sending UL Grants of 136 bits. (Note 1) 


- 


- 


- 


- 




EXCEPTION: In parallel to the events 
described in step 4, step 1 specified in Table 
7.1 .4.4.3.5.2-2 should take place. 










- 


EXCEPTION: Step 6 shall be repeated twice 


- 


- 


- 


- 


6 


Check: Does UE transmit a IVIAC PDU 
containing a Short BSR with 'LCG ID' field set 
to '01' (logicalChannelGroup 1) and Buffer 
Size Index > 0? 


— > 


MAC PDU (LCID='11101', LCG 
ID='01', Buffer Size index > 0) 


2 


P 


7 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


- 


EXCEPTION: Step 8 shall be repeated for 30 
times 


- 


- 


- 


- 


8 


The SS transmits a IVIAC PDU containing an 
RLC PDU on logical channel 3 (LCG ID 2), 
which contains an RLC SDU of size 14 bytes. 


<— 


MAC PDU (RLC SDU) 






9 


The SS responds to any scheduling grants by 
sending UL Grants of 136 bits. (Note 1) 


- 


- 


- 


- 




EXCEPTION: In parallel to the events 
described in step 4, step 1 specified in Table 
7.1 .4.4.3.5.2-2 should take place. 










- 


EXCEPTION: Step 10 shall be repeated twice. 


- 


- 


- 


- 


10 


Check: Does UE transmit a MAC PDU 
containing a Long BSR with 'Buffer size#2' 
(LCG ID=1) and 'Buffer size#3' (LCG ID=2) 
fields set to value > '0'? (Note 2) 


— > 


MAC PDU (LCID='1 1110', Buffer 
size#2 index > 0, Buffer size#3 
index > 0) 


1 


P 


11 


The UE transmits MAC PDUs containing the 
remaining RLC SDUs as sent by the SS in 
steps 2 and 6. 


-> 


MAC PDU (complete RLC SDU or 
RLC SDU segment) 






Note 1. UL grant of 136 bits {Itbs=9, NpRB=^, TS 36.213 Table 7.1.7.2.1-1) is chosen such that the UE can return 
one RLC SDU without padding. RLC SDL) size is 14 bytes, size of AIVID PDU header is 2 bytes, size of 
IVIAC header is 1 byte (1 byte for IVIAC SDU sub-header using last R/R/E/LCID sub-header), i.e. setting UL 
grant to 1 7 bytes (1 36 bits) enable UE to either to send a complete RLC SDU or a Short or Long BSR 
when BSR is triggered. 

Note 2. Buffer size fields in Long BSR are number #1 to #4 in 36.321 (Clause 6.1.3.1) which maps to LCG ID 
values to 3, i.e. LCG ID=1 associates with Buffer size#2 field, and LCG ID=2 associates with Buffer 
size#3, in the Long BSR MAC control element. 

Note 3: SS transmit an UL grant of 32 bits (/res=0, Nprb=2, TS 36.213 Table 7.1 .7.2.1-1) to allow UE to transmit a 
Regular BSR triggered by the new data received logicalChannelGroup 2 and 1 in steps 2 and 3. This to 
enable testing of Padding BSR which has lower priority than Regular BSR. 
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Table 7.1.4.8.3.2-2: Parallel behaviour 



St 


Procedure 


■message Sequence 


TP 


Verdict 




U-S 


■message 


1 


The UE transmits a MAC PDU containing a 
complete RLC SDU, RLC SDL) segments or 
BSR and RLC SDU segments. 


— > 


MAC PDU 







7.1.4.8.3.3 
None. 



Specific Message Contents 



7.1.4.10 MAC-Padding 

7.1.4.10.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is to transmit a MAC PDU with padding exceeding 2 bytes } 
then { Padding goes to the end of the MAC PDU } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is to transmit a MAC PDU with with single-byte padding and there is a data MAC PDU 
subheader present } 

then { UE is insering padding MAC PDU subheader before the first Data MAC PDU subheader } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is to transmit a MAC PDU with with two-byte padding and there is a data MAC PDU 
subheader } 

then { UE is inserting two padding MAC PDU subheaders before the first data MAC PDU subheader 
} 

} 

(4) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is to transmit a MAC PDU with single-byte padding and there is no data MAC PDU 
subheader but a MAC Control element is present } 

then { UE is inserting a padding MAC PDU subheader before the last Control MAC PDU 
subheader } 
} 

Editor's note: TP 3 to 6 do not follow a stimulus/response scheme. Also, they are not independent. 

7.1.4.10.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321 , clause 6.1.2. 
[TS 36.321 clause 6.1.2] 



Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required but cannot be 
achieved by padding at the end of the MAC PDU. 

When single-byte or two-byte padding is required but cannot be achieved by padding at the end of the MAC PDU, one 
or two MAC PDU sub-headers corresponding to padding are inserted before the first MAC PDU sub header 
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corresponding to a MAC SDU; or if such sub header is not present, before the last MAC PDU sub header corresponding 
to a MAC control element. 

A maximum of one MAC PDU can be transmitted per TB per UE.. 



R/R/E/LCID R/R/E/LCID[/F/L] R/R/E/LCID/F/L R/R/E/LCID/F/L _ _ _ R/R/E/LCID/F/L R/R/E/LCID padding 
sub-header sub-header sub-header sub-header " " " sub-header sub-header 



MAC header 



MAC Control 
element 1 



MAC Control 
element 2 



MAC SDU 



MAC SDU 



Padding 
(opt) 



■^ MAC payload ► 

Figure 6.1.2-3: lUIAC PDU consisting of lUIAC header, lUIAC control elements, MAC SDUs and padding 



7.1.4.10.3 




7.1.4.10.3.1 




System SirriL 


lator: 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 



Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 
- MAC configuration setting are as specified in table 7.1.4.10.3.1-1. 
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Table 7.1.4.10.3.1-1: MAC Configuration Settings 



Parameter 


Value 


periodicBSR-Timer 


Infinity 



7.1.4.10.3.1 



Test procedure sequence 



Table 7.1.4.10.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


2 


The SS transmits a IVIAC PDU containing an 
RLC AIVID PDU of size 8 bytes. 


<— 


MAC PDU(AMD PDU) 


- 


- 


3 


The SS waits [1 TTIs]. (Note 5) 


- 


- 


- 


- 


4 


The SS transmits an uplink grant of size 152 
bits. (Note 1) 


<— 


(UL grant) 


- 


- 


5 


Check: Does the UE transmit a MAC PDU with 
a IVIAC SDU of length 8 bytes and where the 
last MAC sub-header has the Extension field 
'E' set to '0' and the Logical Channel ID field 
'LCID' set to '11111'? 


— > 


MAC PDU (MAC SDU sub-header 
(L=8 bytes). Padding MAC sub- 
header (E='0', LCID='11111'), 
BSR, MAC SDU, padding) 


1 


P 


6 


The SS transmits a MAC PDU containing an 
RLC AMD PDU of size 10 bytes. 


<— 


MAC PDU(AMD PDU) 


- 


- 


7 


The SS waits [1 TTIs]. (Note 5) 


- 


- 


- 


- 


8 


The SS transmits an uplink grant of size 120 
bits. (Note 2) 


<— 


(UL grant) 


- 


- 


9 


Check: Does the UE transmit a MAC PDU with 
a MAC SDU of length 10 bytes and with a 
padding MAC sub-header, with Extension field 
'E' is set to '1 ' and the Logical Channel ID field 
'LCID' is set to '1 1 1 1 1 ', inserted before the 
MAC SDU sub-header? 


— > 


MAC PDU (Padding MAC-sub- 
header(E='1', LCID='11111'), 
MAC SDU sub-header (L=10 
bytes), MAC SDU) 


2 


P 


10 


The SS transmits a MAC PDU containing an 
RLC AMD PDU of size 5 bytes. 


<— 


MAC PDU (AMD PDU) 


- 


- 


11 


The SS waits [1 TTIs]. (Note 5) 


- 


- 


- 


- 


12 


The SS transmits an uplink grant of size 120 
bits. (Note 3) 


<— 


(UL grant) 


- 


- 


13 


Check: Does the UE transmit a MAC PDU with 
two padding MAC sub-header, with Extension 
field 'E' is set to '1 ' and the Logical Channel ID 
field 'LCID' is set to '1 1 1 1 1 ', inserted after the 
BSR sub-header, but before the MAC SDU 
sub-header? 


— > 


MAC PDU (BSR sub-header, 
Padding MAC-sub-header#1 
(E='1', LCID='11111'), Padding 
MAC-sub-header#2(E='1', 
LCID='11111'), MAC SDU sub- 
header (L=5 bytes), BSR, MAC- 
SDU) 


3 


P 


14 


The SS transmits a Timing Advance command 
and does not send any subsequent timing 
alignments. Start Timer_T1 = Time Alignment 
timer value on SS. 


<— 


MAC PDU 

(Timing Advance Command) 






15 


The SS waits until Timer_T1 expires and then 
transmits a MAC PDU containing an RLC AMD 
PDU with polling enabled. 


<— 


MAC PDU (AMD PDU (P=1)) 






16 


The UE transmits a preamble on PRACH. 


~> 


(PRACH preamble) 


- 


- 


17 


The SS transmits a Random Access 
Response, with an UL Grant of 32-bits. (Note 
4) 


<— 


Random Access Response 






18 


Check: Does the UE transmit a MAC PDU with 
a padding MAC sub header with Extension 
field 'E' is set to '1 ' and 'LCID' field set to 
'11111' (8-bits) inserted before a Control sub- 
header (8-bits) and a C-RNTI MAC Control 
Element (16-bits)? 


— > 


MAC PDU (Padding MAC-sub- 
header#1 (E='1', LCID='11111'), 
MAC Control sub-header, C-RNTI 
control element) 


4 


P 


19 


The SS transmits a MAC PDU with a UE 
Contention Resolution Identity Control 


<— 


MAC PDU (UE Contention 
Resolution Identity) 


- 


- 
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Element. 










20 


The SS transmits an uplink grant enabling UE 
to transmit a RLC STATUS PDU. 


<— 


(UL grant) 


- 


- 


21 


The UE transmits an RLC STATUS PDU. 


— > 


MAC PDU(RLC STATUS PDU) 


4 


P 


Note 1 : UL grant of 152 bits (Itbs=0, Nprb=6, see TS 36.213 Table 7.1.7.2.1-1) is cliosen such that the MAC PDU 
padding will be larger than 2 bytes. RLC SDU size is 8 bytes, size of AMD PDU header is 2 bytes, size of 
MAC header is 3 bytes (2 bytes for MAC SDU sub-header using 7-bit LI and 1 byte for BSR sub-header) 
and size of Short BSR is 1 byte, equals to 1 12 bits (14 bytes) and resulting into 40 bits padding. 

Note 2: UL grant of 120 bits (/res=0, Nprb=5, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that the MAC PDU 
padding will be a single byte. RLC SDU size is 10 bytes, size of AMD PDU header is 2 bytes and size of 
MAC header is 2 bytes for MAC SDU sub-header (using 7-bit LI), equals to 1 12 bits (14 bytes) and 
resulting into 1 single byte padding. 

Note 3: UL grant of 120 bits (/tss=0, Nprb=5, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that the MAC PDU 
padding will be equal to 2 bytes. RLC SDU size is 5 bytes, size of AMD PDU header is 2 bytes, size of 
MAC header is 3 bytes (2 bytes for MAC SDU sub-header using 7-bit LI and 1 byte for BSR sub-header) 
and size of Long BSR is 3 bytes, equals to 104 bits (13 bytes) and resulting into two-bytes padding. 

Note 4: UL grant of 32 bits (/tss=0, Nprb=2, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that the MAC PDU 
padding will be equal a single byte. 

Note 5: The wait time is specified to ensure that the UE is ready to loop back the data when the grant is received. 



7.1.4.10.3.3 
None. 



Specific Message Contents 



7.1 .4.1 1 Correct HARQ process handling 

7.1.4.11.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established} 
ensure that { 

when { UE receives an UL Grant with incremented NDI and has data is available for transmission} 
then { UE transmits a new MAC PDU using redundency version 0} 
} 

(2) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established and having transmitted a MAC PDU less 
than maxHARQ-Tx times } 
ensure that { 

when { UE receives a NACK and no uplink grant is included for the next TTI corresponding to the 
HARQ process } 

then { UE performs non adaptive retranmission of the MAC PDU with redundency version incremented 
by one of the last (re) transmission [0,2,3,1 order]} 
} 

(3) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established and having transmitted a MAC PDU less 
than maxHARQ-Tx times } 
ensure that { 

when { UE receives a uplink grant on PDCCH for the next TTI corresponding to the HARQ process with 
old NDI [not incremented], irrespective of ACK/NACK is received for previous (re) transmission} 

then { UE performs an adaptive retranmission of the MAC PDU with redundency version as received 
on PDCCH } 

} 

(4) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established and having transmitted a MAC PDU less 
than maxHARQ-Tx times } 
ensure that { 

when { UE receives a ACK and no uplink grant is included for the next TTI corresponding to the 
HARQ process } 

then { UE does not retransmit the MAC PDU} 
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(5) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established and having transmitted a MAC PDU 
maxHARQ-Tx times } 
ensure that { 

when { UE receives an uplink grant on PDCCH for the next TTI corresponding to the HARQ process 
with not incremented NDI } 

then { UE flushes the HARQ buffer and does not retransmit the MAC PDU} 
} 

(6) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established and having transmitted a MAC PDU less 
than maxHARQ-Tx times } 
ensure that { 

when { UE receives an uplink grant on PDCCH for the next TTI corresponding to the HARQ process 
with incremented NDI, and data are not available for transmission} 

then { UE flushes the HARQ buffer and does not transmit any MAC PDU} 

} 

(7) 

with { UE in E-UTRA RRC_ CONNECTED state with DRB established and having transmitted a MAC PDU 
maxHARQ-Tx times } 
ensure that { 

when { UE receives a NACK and no uplink grant is included for the next TTI corresponding to the 
HARQ process} 

then { UE does not transmit any MAC PDU } 
} 

7.1 .4.1 1 .2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321, clause 5.4.2.1 & 
5.4.2.2. 

[TS 36.321, clause 5.4.2.1] 

There is one HARQ entity at the UE, which maintains a number of parallel HARQ processes allowing transmissions to 
take place continuously while waiting for the feedback on the successful or unsuccessful reception of previous 
transmissions. 

The number of parallel HARQ processes is specified in [2], clause 8. 

At a given TTI, if an uplink grant is indicated for the TTI, the HARQ entity identifies the HARQ process for which a 
transmission should take place. It also routes the received feedback (ACK/NACK information), MCS and resource, 
relayed by the physical layer, to the appropriate HARQ process. 

If TTI bundling is configured, the parameter TT1_BUNDLE_S1ZE provides the number of TTIs of a TTI bundle. 
Within a bundle HARQ retransmissions are non-adaptive and shall be performed without waiting for feedback from 
previous transmissions according to TT1_BUNDLE_S1ZE. The feedback for a bundle is only received for the TTI 
corresponding to TTI_BUNDLE_SIZE. A retransmission of a TTI bundle is also a TTI bundle. 

For transmission of an uplink message containing the C-RNTI MAC control element or an uplink message including a 
CCCH SDU during Random Access (see section 5.1.5) TTI bundling does not apply. 

For each TTI, the HARQ entity shall: 

identify the HARQ process associated with this TTI; 

if an uplink grant has been indicated for this TTI: 

if the received grant was not addressed to a Temporary C-RNTI on PDCCH and if the NDI provided in the 
associated HARQ information has been toggled compared to the value in the previous transmission of this 
HARQ process; or 

if this is the very first transmission for this HARQ process (i.e. , no previous NDI is available); or 

if the uplink grant was received in a Random Access Response: 

- if there is an ongoing Random Access procedure and there is a MAC PDU in the [Message3] buffer: 
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- obtain the MAC PDU to transmit from the [Message3] buffer. 

else: 

obtain the MAC PDU to transmit from the "Multiplexing and assembly" entity; 

deliver the MAC PDU and the uplink grant and the HARQ information to the identified HARQ process; 

instruct the identified HARQ process to trigger a new transmission. 

else: 

deliver the uplink grant and the HARQ information (redundancy version) to the identified HARQ process; 

instruct the identified HARQ process to generate an adaptive retransmission. 

else, if the HARQ buffer of the HARQ process corresponding to this TTI is not empty: 

instruct the identified HARQ process to generate a non-adaptive retransmission. 

When determining if NDI has been incremented compared to the value in the previous transmission UE shall ignore 
NDI received in all uplink grants on PDCCH for its Temporary C-RNTI. 

NOTE: A retransmission triggered by the HARQ entity should be cancelled by the corresponding HARQ process 
if it collides with a measurement gap or if a non-adaptive retransmission is not allowed. 

[TS 36.321, clause 5.4.2.2] 

Each HARQ process is associated with a HARQ buffer. 

Each HARQ process shall maintain a state variable CURRENT_TX_NB, which indicates the number of transmissions 
that have taken place for the MAC PDU currently in the buffer. When the HARQ process is established, 
CURRENT_TX_NB shall be initialized to 0. 

The sequence of redundancy versions is 0, 2, 3, 1. The variable CURRENT_IRV is an index into the sequence of 
redundancy versions. This variable is up-dated modulo 4. 

New transmissions and adaptive retransmissions are performed on the resource and with the MCS indicated on PDCCH, 
while a non-adaptive retransmission is performed on the same resource and with the same MCS as was used for the last 
made transmission attempt. 

The UE is configured with a Maximum number of HARQ transmissions and a Maximum number of Message3 HARQ 
transmissions by RRC. For transmissions on all HARQ processes and all logical channels except for transmission of a 
MAC PDU stored in the [Message3] buffer, maximum number of transmissions shall be set to Maximum number of 
HARQ transmissions. For transmission of a MAC PDU stored in the [Message3] buffer, maximum number of 
transmissions shall be set to Maximum number of Message3 HARQ transmissions. 

If the HARQ entity requests a new transmission, the HARQ process shall: 

- set CURRENT_TX_NB to 0; 

- set CURRENT_1RV to 0; 

- store the MAC PDU in the associated HARQ buffer; 

store the uplink grant received from the HARQ entity; 

if there is no measurement gap at the time of the transmission or if the MAC PDU was obtained from the 
[Message3] buffer: 

generate a transmission as described below. 



If the HARQ entity requests a retransmission, the HARQ process shall: 
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- increment CURRENT_TX_NB by 1 ; 

if there is no measurement gap at the time of the retransmission: 
if the HARQ entity requests an adaptive retransmission: 
store the upHnk grant received from the HARQ entity; 

- set CURRENT_IRV to the value provided in the HARQ information; 
generate a transmission as described below. 

else if the HARQ entity requests a non-adaptive retransmission: 

if TTI bundling is not configured and the last received feedback for this HARQ process is a HARQ 
NACK; or 

- if TTI bundling is configured and CURRENT_TX_NB modulo TTI_BUNDLE_S1ZE = and the last 
received feedback for this HARQ process is a HARQ NACK; or 

- if TTI bundling is configured and CURRENT_TX_NB modulo TTI_BUNDLE_SIZE != 0: 

generate a transmission as described below. 

NOTE: When receiving a HARQ ACK alone, the UE keeps the data in the HARQ buffer. 

NOTE: When a non-adaptive retransmission does not take place due to the occurrence of a measurement gap, the 
last received HARQ feedback for this HARQ process is the feedback corresponding to the preceding 
transmission. 

To generate a transmission, the HARQ process shall: 

instruct the physical layer to generate a transmission according to the stored uplink grant with the redundancy 
version corresponding to the CURRENT_IRV value; 

- increment CURRENTJR V by 1 ; 

if there is a measurement gap at the time of the feedback reception for this transmission, consider the feedback 
coinciding with the measurement gap to be a HARQ ACK i.e. the "last received feedback" for a retransmission 
of this HARQ process will be considered as a HARQ ACK. 

The HARQ process shall: 

if CURRENT_TX_NB = maximum number of transmissions - 1 : 
- flush the HARQ buffer; 

The HARQ process may: 

if CURRENT_TX_NB = maximum number of transmissions - 1 ; and 

if the last feedback received (i.e., the feedback received for the last transmission of this process) is a HARQ 
NACK except for the transmission of a MAC PDU stored in the [Message3] buffer: 

notify the relevant ARQ entities in the upper layer that the transmission of the corresponding RLC PDUs 
failed. 
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7.1.4.11.3 Test description 

7.1.4.11.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

System information take into account the parameters in table 7.1.2.11.3.1-1. 

UE: 

None. 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18], with the DRB for the default EPS bearer 
context configured with RLC in UM mode. 

The loop back size is set in such a way that one RLC SDU in DL shall result in 1 RLC SDU's in UL. 

No UL Grant is allocated, PUCCH is configured for sending Scheduling Requests. 

Table 7.1.2.11.3.1-1: RACH Parameters 



Parameter 


Value 


maxHARQ-Tx 


n8 
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7.1.4.11.3.2 



Test procedure sequence 



Table 7.1.4.11.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS Transmits a valid MAC PDU 
containing RLC PDU 


<— 


MAC PDU 


- 


- 


2 


Checl<: Does the UE transmit a Scheduling 
Request? 


— > 


Scheduling Request 


- 


- 


3 


The SS allocate UL Grant for one HARQ 
process X, sufficient for one RLC SDU to be 
loop backed in a TTI, and NDI indicates new 
transmission 


<— 


Uplink Grant 






4 


Check: Does the UE transmit a MAC PDU 
including one RLC SDU, in HARQ process X, 
redundancy version 0? 


— > 


MAC PDU 


1 


P 


5 


The SS transmits a NACK 


<— 


HARQ NACK 


- 


- 


6 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X, redundancy 
version 2? 


— > 


MAC PDU 


2 


P 


7 


The SS transmits a NACK 


<— 


HARQ NACK 


- 


- 


8 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X, redundancy 
version 3? 


— > 


MAC PDU 


2 


P 


9 


The SS transmits a NACK 


<— 


HARQ NACK 


- 


- 


10 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X, redundancy 
version 1 ? 


— > 


MAC PDU 


2 


P 


11 


The SS transmits a NACK 


<— 


HARQ NACK 


- 


- 


12 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X, redundancy 
version 0? 


— > 


MAC PDU 


2 


P 


13 


The SS transmits a NACK 


<— 


HARQ NACK 


- 


- 


14 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X, redundancy 
version 2? 


— > 


MAC PDU 


2 


P 


15 


The SS transmits an ACK 


<~ 


HARQ ACK 


- 


- 


16 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X? 


— > 


MAC PDU 


4 


F 


17 


The SS transmits an UL grant corresponding 
to TTI for HARQ process X, with NDI not 
incremented and redundancy version to be 
used as '1' 


<— 


Uplink Grant 






18 


Check: Does the UE transmit a MAC PDU in 
for HARQ process X, using redundancy 
version 1 ? 


--> 


MAC PDU 


3 


P 


19 


The SS transmits a NACK 


<— 


HARQ NACK 


- 


- 


20 


The SS transmits an UL grant corresponding 
to next TTI for HARQ process X, with NDI not 
incremented and redundancy version to be 
used as '3' 


<— 


Uplink Grant 






21 


Check: Does the UE transmit a MAC PDU in 
the next TTI for HARQ process X, using next 
redundancy version 3? 


— > 


MAC PDU 


3 


P 


22 


The SS transmits a NACK 


<— 


HARQ NACK 






23 


Check: Does the UE transmit a MAC PDU in 
the next TTIs corresponding to HARQ process 
X? 


— > 


MAC PDU 


7 


F 


24 


The SS transmits an UL grant corresponding 
to TTI for HARQ process X, with NDI not 
incremented 


<— 


Uplink Grant 






25 


Check: Does the UE transmit a MAC PDU in 
the next TTIs corresponding to HARQ process 
X? 


— > 


MAC PDU 


5 


F 


26 


The SS Transmits a valid MAC PDU 
containing RLC PDU 


<— 


MAC PDU 


- 


- 
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27 


The UE transmits a Scheduling Request 


— > 


Scheduling Request 


- 


- 


28 


The SS allocates UL Grant for one HARQ 
process Y, sufficient for one RLC SDU to be 
loop backed in a TTI, and NDI indicates new 
transmission 


<— 


Uplink Grant 






29 


Check: Does the UE transmit a MAC PDU 
including one RLC SDU, in HARQ process Y, 
redundancy version 0? 


— > 


MAC PDU 


1 


P 


30 


The SS allocates UL Grant for one HARQ 
process Y, sufficient for one RLC SDU to be 
loop backed in a TTI, and NDI indicates new 
transmission 


<— 


Uplink Grant 






31 


Check: Does the UE transmit a MAC PDU in 
the next TTIs corresponding to HARQ process 
Y? 


— > 


MAC PDU 


6 


F 



7.1.4.11.3.3 
None. 



Specific message contents 



7.1 .4.13 MAC PDU header handling 

7.1.4.13.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE has a MAC SDU to be transmitted that is less smaller 128 bytes } 
then { UE sets F field to } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE has a MAC SDU to be transmitted that is larger than 128 bytes } 
then { UE sets F field to l} 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE inserts a R/R/E/LCID field in the MAC header and there is a subsequent R/R/E/LCID field 
to be inserted } 

then { UE sets E field to 1 } 

} 

(4) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE inserts a R/R/E/LCID field in the MAC header and a MAC SDU or a MAC control element 
starts at the next byte } 

then { UE sets E field to 0} 

} 

(5) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE inserts the last MAC sub-header in the MAC PDU } 

then { UE inserts a MAC sub-header consist solely of the four header fields R/R/E/LCID } 
} 

(6) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE inserts padding at the end of a MAC PDU} 
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then { UE inserts the last MAC sub-header as a padding MAC subheader consisting solely of the 
four header fields R/R/E/LCID with LCID set to Padding } 



7.1.4.13.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.321 clause 6.1.2 
and 6.2.1. 

[TS 36.321, clause 6.1.2] 

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC 
control elements, and optionally padding; as described in Figure 6.1.2-3. 

Both the MAC header and the MAC SDUs are of variable sizes. 

A MAC PDU header consists of one or more MAC PDU sub-headers; each sub header corresponding to either a MAC 
SDU, a MAC control element or padding. 

A MAC PDU sub header consists of the six header fields R/R/E/LCID/F/L but for the last sub header in the MAC PDU 
and for fixed sized MAC control elements. The last sub header in the MAC PDU and sub-headers for fixed sized MAC 
control elements consist solely of the four header fields R/R/E/LCID. It follows that a MAC PDU sub header 
corresponding to padding consists of the four header fields R/R/E/LCID. 










1 1 1 1 1 




R 


R 


E 


LCID 


F 


L 


L 



Octi 
Oct 2 
Oct 3 



R/R/E/LCID/F/L sub-header with 
7-bits L field 



R/R/E/LCID/F/L sub-header with 
15-bitsL field 



Figure 6.1.2-1: R/R/E/LCID/F/L lUIAC sub header 



R R 



LCID 



Octi 



R/R/E/LCID sub-header 

Figure 6.1.2-2: R/R/E/LCID MAC sub header 

MAC PDU sub-headers have the same order as the corresponding MAC SDUs, MAC control elements and padding. 

MAC control elements are always placed before any MAC SDU. 

Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required but cannot be 
achieved by padding at the end of the MAC PDU. 

When single-byte or two-byte padding is required but cannot be achieved by padding at the end of the MAC PDU, one 
or two MAC PDU sub-headers corresponding to padding are inserted before the first MAC PDU sub header 
corresponding to a MAC SDU; or if such sub header is not present, before the last MAC PDU sub header corresponding 
to a MAC control element. 

A maximum of one MAC PDU can be transmitted per TB per UE. 
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R/R/E/LCID 
sub-header 



R/R/E/LCID[/F/L] 
sub-header 



R/R/E/LCID/F/L 
sub-header 



R/R/E/LCID/F/L 
sub-header 



R/R/E/LCID/F/L R/R/E/LCID padding 
sub-header sub-header 



MAC header 



MAC Control 
element 1 



MAC Control 
element 2 



MAC SDU 



MAC SDU 



Padding 
(opt) 



-MAC payload- 



Figure 6.1.2-3: MAC PDU consisting of IVIAC header, IVIAC control elements, MAC SDUs and padding 

[TS 36.321, clause 6.2.1] 

The MAC header is of variable size and consists of the following fields: 

LCID: The Logical Channel ID field identifies the logical channel instance of the corresponding MAC SDU or 
the type of the corresponding MAC control element or padding as described in tables 6.2.1-1 and 6.2. 1-2 for the 
DL and UL-SCH respectively. There is one LCID field for each MAC SDU, MAC control element or padding 
included in the MAC PDU. The LCID field size is 5 bits; 

L: The Length field indicates the length of the corresponding MAC SDU or MAC control element in bytes. 
There is one L field per MAC PDU sub header except for the last sub header and sub-headers corresponding to 
fixed-sized MAC control elements. The size of the L field is indicated by the F field; 

F: The Format field indicates the size of the Length field as indicated in table 6.2. 1-3. There is one F field per 
MAC PDU sub header except for the last sub header and sub-headers corresponding to fixed-sized MAC control 
elements. The size of the F field is 1 bit. If the size of the MAC SDU or MAC control element is less than 128 
bytes, the UE shall set the value of the F field to 0, otherwise the UE shall set it to 1 ; 

E: The Extension field is a flag indicating if more fields are present in the MAC header or not. The E field is set 
to "1" to indicate another set of at least R/R/E/LClD fields. The E field is set to "0" to indicate that either a MAC 
SDU, a MAC control element or padding starts at the next byte; 

R: Reserved bits. 

The MAC header and sub-headers are octet aligned. 



Table 6.2.1-2 Values of LCID for UL-SCH 



Index 


LCID values 


00000 


CCCH 


00001-01010 


Identity of the logical channel 


01011-11001 


Reserved 


11010 


Power Headroom Report 


11011 


C-RNTI 


11100 


Truncated BSR 


11101 


Short BSR 


11110 


Long BSR 


11111 


Padding 
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Table 6.2.1-3 Values of F field: 



Index 


Size of Length field (in bits) 





7 


1 


15 



7.1.4.13.3 


Test description 


7.1.4.13.3.1 


Pre-test conditions 


System Simulator 




- Cell 1 




UE 




None. 





Preamble 

The UE is in state Loopback Activated (state 4) according to [18]. 

2 AM DRBs are configured with the parameters specified in table 7.1.4.13.3.1-1. 

Table 7.1.4.13.3.1-1: Logical Channel Configuration Settings 



Parameter 


DRB1 


DRB2 


LogicalChannel-ldentity 


3 


4 


Priority 


7 


6 


prioritizedBitRate 


Okbs 


Okbs 


logicalChannelGroup 


2 


1 


periodicBSR-Timer 


infinity 
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7.1.4.13.3.2 



Test procedure sequence 



Table 7.1.4.13.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


2 


The SS transmits a MAC PDU containing a 
MAC SDU of size 127 bytes (RLC SDU of size 
1 25 bytes + AMD PDU header 2 bytes with the 
Logical Channel ID field 'LCID' set to '0001 1 ', 
Format field 'F' set to '0' and Length field 'L' 
set to '127' in the associated MAC SDU sub- 
header. 


<— 


MAC PDU (MAC sub-header ( 
LCID='00011', F='0', L='127'), 
AMD PDU) 






3 


The SS waits [1 TTIs]. (Note 5) 


- 


- 


- 


- 


4 


The SS transmits an uplink grant of size 1064 
bits. (Note 1) 


<— 


(UL grant) 


- 


- 


5 


Check: does the UE transmit a MAC PDU with 
a MAC SDU sub-header with Logical Channel 
ID field 'LCID' set to '0001 1 ', Format field 'F' 
set to '0' and Length field 'L' set to '1 27'? 


— > 


MAC PDU (MAC sub-header ( 
LCID='00011', F='0', L='127' 
bytes), AMD PDU) 


1 


P 


6 


The SS transmits a MAC PDU containing a 
MAC SDU of size 129 bytes RLC SDU of 127 
bytes -1- AMD PDU header 2 bytes) with the 
Logical Channel ID field 'LCID' set to '0001 1 ', 
Format field 'F' set to '1 ' and Length field 'L' 
set to '129' in the associated MAC SDU sub- 
header. 


<— 


MAC PDU (MAC sub-header 
(LCID='00011', F='1', L='129'), 
AMD PDU) 






7 


The SS waits [1 TTIs]. (Note 5) 


- 


- 


- 


- 


8 


The SS transmits an uplink grant of size 1064 
bits. (Note 2) 


<— 


(UL grant) 


- 


- 


9 


Check; Does the UE transmit a MAC PDU 
with a MAC SDU sub-header with Format field 
'F' set to '1 ' and Logical Channel ID field 'LCID' 
set to '00011'? 


-> 


MAC PDU (MAC sub-header 
(LCID='00011', F='1', L='129'), 
AMD PDU) 


2 


P 


10 


The SS transmits an RLC STATUS PDU to 
acknowledge correctly received data 


<— 


RLC STATUS PDU (ACK_SN=2) 


- 


- 


11 


The SS transmits a MAC PDU containing two 
MAC SDUs, the first containing a 1 1 byte RLC 
SDU with LCID set to '0001 1 ' and the second 
containing s 10 byte RLC SDU with LCID set 
to '00100'. 


<— 


MAC PDU (MAC sub-header 
(E='1', LCID='00011', F='0', 
L='1 1 '), MAC sub-header (E='0', 
LCID='00100', F='0'), AMD PDU, 
AMD PDU) 






12 


The SS waits [1 TTIs]. (Note 5) 


- 


- 


- 


- 


13 


The SS transmits an uplink grant of size 176 
bits. (Note 3) 


<— 


(UL grant) 


- 


- 


14 


Check: Does the UE return a MAC PDU of 
length 176 bits containing two MAC sub- 
headers where the first MAC sub-header has 
the Expansion bit 'E' set to '1 ' and including a 
LCID field set to '0001 1 ' and a Length field set 
to '11'; or including a LCID set to '00100' and a 
Length field set to '1 0' bytes; and the second 
MAC sub-header has the Expansion bit 'E' set 
to '0' and not including any Length field? 


-> 


MAC PDU (MAC sub-header 
(E='1', (LCID='00011', L='11')or 
(LCID='00100',L='10'), MAC sub- 
header (E='0', no Length field 
present), AMD PDU, AMD PDU) 


3,4, 
5 


P 


15 


SS transmits an RLC STATUS PDU to 
acknowledge correctly received data 


<— 


RLC STATUS PDU (ACK_SN=4) 


- 


- 


16 


The SS transmits a MAC PDU containing two 
MAC SDUs, the first containing a 10 byte RLC 
SDU with LCID set to '0001 1 ' and the second 
containing a 9 byte RLC SDU with LCID set to 
'00100'. 


<— 


MAC PDU (MAC sub-header 
(E='1', LCID='00011', F='0', 
L='10'), MAC sub-header (E='1', 
LCID='00100', F='0', L='9'), 
padding MAC sub-header (E='0', 
LCID='11111'),AMDPDU,AMD 
PDU, padding) 






17 


SS waits [10 TTIs]. (Note 5) 


- 


- 


- 


- 


18 


The SS transmits an uplink grant of size 224 
bits. (Note 4) 


<— 


(UL grant) 


- 


- 
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19 



Check: Does the UE return a MAC PDU of 
length 224 bits containing four IVIAC sub- 
headers where the first two IVIAC sub-header 
have the Expansion bit 'E' set to '1 ' and the 
last IVIAC sub-header has the Expansion bit 'E' 
set to '0' and the LCID field set to '11 1 11 '? 



MAC PDU (MAC sub-header 
(E='1', F='0'), MAC sub-header 
(E='1', F='0'), Long BSR MAC 
sub-header (E='1', LCID='11110', 
F='0'), padding MAC sub-header 
(E='0', LCID='1 1111'), AMD PDU, 
AMD PDU, Long BSR, padding) 



3,4, 
6 



Note 1. UL grant of 1064 bits (/Tes=17, Nprb=3, TS 36.213 Table 7.1.7.2.1-1) is chosen to enable UE to transmit a 
MAC SDU of size 127 bytes in a MAC PDU (125 bytes RLC SDU size -i- 2 bytes AMD PDU header + 2 
bytes MAC header (7 bit LI) = 1 29 bytes = 1 032 bits < 1 064 bits) 

Note 2. UL grant of 1096 bits (/Tes=17, Nprb=3, TS 36.213 Table 7.1.7.2.1-1) is chosen to enable UE to transmit a 
MAC SDU of size 129 bytes in a MAC PDU (127 bytes RLC SDU size -i- 2 bytes AMD PDU header -i- 3 
bytes MAC header (15 bit LI) = 132 bytes = 1056 bits < 1064 bits) 

Note 3. UL grant of 176 bits (/res=1 , Nprb=5, TS 36.213 Table 7.1 .7.2.1-1) is chosen to enable UE to transmit two 
MAC SDUs, one of size 1 1 and one of size 10 bytes, in a MAC PDU (9 bytes RLC SDU -i- 2 bytes AMD 
PDU header -i- 8 bytes RLC SDU + 2 bytes MAC sub-header (7 bit LI) -i- one byte MAC sub-header 
(R/R/E/LCID) = 22 bytes = 176 bits) 

Note 4. UL grant of 224 bits (Itbs=5, Nprb=5, TS 36.213 Table 7.1 .7.2.1-1) is chosen to enable UE to transmit two 
MAC SDUs of size 10 and 9 bytes in a MAC PDU (8 bytes RLC SDU -i- 2 bytes AMD PDU header -i- 7 
bytes RLC SDU + 2 byte padding -i- 3 byte Long BSR + 2x2 bytes MAC sub-header (7 bit LI) + one byte 
BSR header + one byte padding MAC sub-header (R/R/E/LCID) = 28 bytes = 224 bits) 

Note 5: The wait time is specified to ensure that the UE is ready to loop back the data when the grant is received. 



7.1.4.13.3.3 
None. 



Specific Message Contents 



7.1 .4.15 UE Power Headroom Reporting [Periodic reporting] 

7.1.4.15.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_Connected state with DRB established, periodic power headroom reporting 

configured} 

ensure that { 

when { PERIODIC PHR TIMER is configured in RRCConnectionReconf iguration procedre } 
then { UE transmits a MAC PDU contianing Power Headroom MAC Control Element } 
} 

(2) 

with { UE in E-UTRA RRC_Connected state with DRB established, periodic power headroom reporting 

configured} 

ensure that { 

when { PERIODIC PHR TIMER expires and UL resources allocated for new transmission } 
then { UE transmits a MAC PDU contianing Power Headroom MAC Control Element } 



} 



7.1.4.15.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.321 clause 5.4.6 and 
6.1.3.6 

[TS 36.321, clause 5.4.6] 

The Power Headroom reporting procedure is used to provide the serving eNB with information about the difference 
between the UE TX power and the maximum UE TX power (for the positive values of the power headroom) and about 
the difference between the maximum UE TX power and the calculated UE TX power, according to the UL power 
control formula, when it exceeds the maximum UE TX power (for the negative values of the power headroom). 

A Power Headroom Report (PHR) shall be triggered if any of the following events occur: 

the PROHIBlT_PHR_TlMER expires or has expired and the path loss has changed more than 
DL_PathlossChange dB since the last power headroom report; 

- the PERIODIC PHR TIMER expires, in which case the PHR is referred below to as "Periodic PHR"; 
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upon configuration and reconfiguration of a Periodic PHR. 

If the Power Headroom reporting procedure determines that a PHR has been triggered since the last transmission of a 
PHR: 

if the UE has UL resources allocated for new transmission for this TTI: 

obtain the value of the power headroom from the physical layer; 

instruct the Multiplexing and Assembly procedure to generate a PHR MAC control element based on the 
value reported by the physical layer; 

- if the PHR is a "Periodic PHR", restart the PERIODIC PHR TIMER; 

- restart the PROHIBIT_PHR_TIMER. 

NOTE: Even if multiple events occur by the time a PHR can be transmitted, only one PHR is included in the 
MAC PDU. 

[TS 36.321, clause 6.1.3.6] 

The Power Headroom MAC control element is identified by a MAC PDU sub header with LCID as specified in table 
6.2.1-1. It has a fixed size and consists of a single octet defined as follows (figure 6.1.3.6-1): 

R: reserved bits; 

Power Headroom: this field indicates the power headroom. The length of the field is 6 bits. 



R R 



Power Headroom Oct 1 



Figure 6.1.3.5-1 : Power Headroom IVIAC control element 



7.1.4.15.3 


Test description 


7.1.4.15.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



127 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



7.1.4.15.3.2 



Test procedure sequence 

Table 7.1.4.15.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits UL grant for the UE at every 
TTI. 










2 


The SS transmits an 

RRCConnectionReconfiguration message to 
provide Power Headroom parameters 










3 


The UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of Power 
Headroom parameters. 










4 


Checl<: does the UE transmit a IVIAC PDU 
containing Power Headroom iVIAC Control 
Element 


— > 


MAC PDU 


1 


P 


5 


Check: does the UE transmit a MAC PDU 
containing Power Headroom MAC Control 
Element 200ms after step 3? 


— > 


MAC PDU 


2 


P 



Editors Note: It is possible that Power Headroom MAC Control Element of step 3 is received in step 2 itself along 
with RRCConnectionReconfigurationComplete. 

7.1.4.15.3.3 Specific message contents 

Table 7.1. 4.15.3.3-1: RRCConnectionReconfiguration (step 1, Table 8.2.4.6.3.2-2) 



Derivation path: 36.508 table xxx 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEQUENCE { 








RadioResourceConfigDedicated SEQUENCE { 








mac-MainConfig CHOICE { 








explicit SEQUENCE { 








phr-Configuration CHOICE { 








enable SEQUENCE { 








periodicPHR-Timer 


sf200 






prohibitPHR-Timer 


sf 1 000 






dl-PathlossChange 
} 
} 
} 
} 
} 
} 
} 
} 
} 


infinity 







7.1 .4.16 UE Power Headroom Reporting [DL_Pathloss change reporting] 

7.1.4.16.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_Connected state with DRB established, Power headroom reporting for 
DL_PAthloss change configured} 
ensure that { 

when { the DL Pathloss changes and prohibitPHR-Timer is running } 

then { UE does not transmits a MAC PDU containing Power Headroom MAC Control Element } 
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(2) 

with { UE in E-UTRA RRC_Connected state with DRB established, periodic power headroom reporting 

configured} 

ensure that { 

when { prohibitPHR-Timer expires and power headroom report is triggered due to DL Pathloss change 

} 

then { UE transmits a MAC PDU containing Power Headroom MAC Control Element } 

} 

7.1.4.16.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.321 clause 5.4.6 and 
6.1.3.6 

[TS 36.321, clause 5.4.6] 

The Power Headroom reporting procedure is used to provide the serving eNB with information about the difference 
between the UE TX power and the maximum UE TX power (for the positive values of the power headroom) and about 
the difference between the maximum UE TX power and the calculated UE TX power, according to the UL power 
control formula, when it exceeds the maximum UE TX power (for the negative values of the power headroom). 

A Power Headroom Report (PHR) shall be triggered if any of the following events occur: 

the PROHIBIT_PHR_TlMER expires or has expired and the path loss has changed more than 
DL_PathlossChange dB since the last power headroom report; 

- the PERIODIC PHR TIMER expires, in which case the PHR is referred below to as "Periodic PHR"; 

upon configuration and reconfiguration of a Periodic PHR. 

If the Power Headroom reporting procedure determines that a PHR has been triggered since the last transmission of a 
PHR: 

if the UE has UL resources allocated for new transmission for this TTI: 

obtain the value of the power headroom from the physical layer; 

instruct the Multiplexing and Assembly procedure to generate a PHR MAC control element based on the value 
reported by the physical layer; 

- if the PHR is a "Periodic PHR", restart the PERIODIC PHR TIMER; 

- restart the PR0HIB1T_PHR_TIMER. 

NOTE: Even if multiple events occur by the time a PHR can be transmitted, only one PHR is included in the 
MAC PDU. 

[TS 36.321, clause 6.1.3.6] 

The Power Headroom MAC control element is identified by a MAC PDU sub header with LCID as specified in table 
6.2.1-1. It has a fixed size and consists of a single octet defined as follows (figure 6.1.3.6-1): 

R: reserved bits; 

Power Headroom: this field indicates the power headroom. The length of the field is 6 bits. 



Power Headroom Oct 1 



Figure 6.1.3.5-1 : Power l-leadroom lUIAC control element 
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7.1.4.15.3 


Test description 


7.1.4.16.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 
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Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 



7.1.4.16.3.2 



Test procedure sequence 



Table 7.1.4.16.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Exception: SS is configured to continuously 
transmit UL grant for UE, every TTI 










2 


SS transmits an 

RRCConnectionReconfiguration message to 
provide Power Headroom parameters 


<— 


RRCConnectionReconfiguration 






3 


Ttie UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of Power 
Headroom parameters. 


— > 


RRCConnectionReconfigurationC 
ompiete 






4 


thie UE transmit a IVIAC PDU containing Power 
Headroom IVIAC Control Element. 


--> 


MAC PDU 


- 


- 


5 


Wait for T1 = 1 0% of prohibitPHR-Timer. 










6 


Reduce SS power level so as to cause a 
DL Pathless change at UE by 5dB. 










7 


Check : for 80% of prohibitPHR-Timer s\r\ce 
step 6, if the UE transmit a IVIAC PDU 
containing Power Headroom MAC Control 
Element 


— > 


MAC PDU 


1 


F 


8 


Check: after prohibitPHR-Timer ai\er step 4, 
does the UE transmit a IVIAC PDU containing 
Power Headroom IVIAC Control Element 


— > 


MAC PDU 


2 


P 


9 


Increase SS power level so as to cause a 
DL Pathless change at UE by 5dB. 










10 


Check : for 80% of prohibitPHR-Timer s\r\ce 
step 6, if the UE transmit a IVIAC PDU 
containing Power Headroom MAC Control 
Element 


— > 


MAC PDU 


1 


F 


11 


Check: after prohibitPHR-Timer aner step 8, 
does the UE transmit a MAC PDU containing 
Power Headroom MAC Control Element 


— > 


MAC PDU 


2 


P 



Editors Note: It is possible that Power Headroom MAC Control Element of step 3 is received in step 2 itself along 
with RRCConnectionReconfigurationComplete. 
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7.1.4.16.3.3 Specific message contents 

Table 7.1. 4.15.3.3-1: RRCConnectionReconfiguration (step 1, Table 8.2.4.6.3.2-2) 



Derivation patti: 36.508 table xxx 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-rS SEOUENCE { 








RadioResourceConfigDedicated SEQUENCE { 








mac-MainConfig CHOICE { 








explicit SEOUENCE { 








phr-Configuration CHOICE { 








enable SEOUENCE { 








periodicPHR-Timer 


infinity 






prohibitPHR-Timer 


sf 1 000 






dl-PathlossChange 
} 
} 
} 
} 
} 
} 
} 
} 
} 


dB3 







7.2 



RLC 



Editor's note: For test procedure sequences in this section, unless specific indications are provided for uplink grant 
allocations, it may be assumed that for each test step where the contents of the "U-S" column is "— >", at 
least sufficient uplink grant is allocated at the start of the immediately preceding contiguous sequence of 
steps having a "U-S' column which contents is not "<--". 

Editor's note: Test cases in the RLC section shall contain RLC PDU names in the "message" column. When 

something else is in this column, it is indicated with parenthesis. While such notation is unambiguous for 
(UL grant), (RLC SDU#n) should be avoided unless a clear definition is added. 

7.2.1 Transparent Mode 

7.2.2 Unacknowledged Mode 

7.2.2.4 UM RLC/ Reassembly / 1 0-bit SN / 11 -bit "Length Indicators" / LI value > 

PDU size 

Editor's note: conformance requirements are based on 36.322 v8.3.0 i.e. after RAN#4L 

7.2.2.4.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an RLC PDU with Length Indicator value larger than RLC PDU size } 
then { UE discards the RLC PDU } 
} 

7.2.2.4.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 5.5.1. 
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[TS 36.322, clause 5.5.1] 

When an RLC entity receives an RLC PDU that contains reserved or invalid values, the RLC entity shall: 
discard the received PDU. 



7.2.2.4.3 




7.2.2.4.3.1 




System SirriL 


lator: 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 



Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 



7.2.2.4.3.2 



Test procedure sequence 



Table 7.2.2.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: the behaviour described in table 
7.2.2.4.3.2-2 runs in parallel with steps 1 to 5 
below. 










1 


The SS transmits UIVID PDU#1 containing first 
segment of RLCSDU#1. 


<— 


UMD PDU#1 


- 


- 


2 


The SS transmits UMD PDU#2 containing last 
segment of RLC SDU#1 and first segment of 
RLC SDU#2. 


<— 


UMD PDU#2 






3 


The SS transmits UMD PDU#3 containing last 
segment of RLC SDU#2, first segment of RLC 
SDU#3 and with Length Indicator that points 
beyond the end of the RLC PDU#3. 


<- 


UMD PDU#3 






4 


The SS transmits UMD PDU#4 containing last 
segment of RLC SDU#3. 


<— 


UMD PDU#4 


- 


- 


5 


The SS transmits UMD PDU#5 containing RLC 
SDU#4. 


<— 


UMD PDU#5 


- 


- 



Table 7.2.2.4.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


Check: does the UE send RLC SDU#1 ? 


— > 


(RLCSDU#1) 


1 


P 


2 


Check: does the UE send RLC SDU#2? 


— > 


(RLC SDU#2) 


1 


F 


3 


Check: does the UE send RLC SDU#3? 


— > 


(RLC SDU#3) 


1 


F 


4 


Check: does the UE send RLC SDU#4? 


— > 


(RLC SDU#4) 


1 


P 



7.2.2.4.3.3 
None. 



Specific message contents 
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7.2.2.8 DM RLC / In sequence delivery of upper layers PDUs without residual loss of 

RLC PDUs / Maximum re-ordering delay exceeds the T_reordering time 

7.2.2.8.1 Test Purpose (TP) 
(1) 

with { UE having completed loopback activation procedure } 
ensure that { 

when { a PDU or PDU segment is received out of order after T_reordering has expired } 

then { UE discards the correspoding PDU and delivers all correctly received RLC SDUs to upper 
layer in the correct order } 
} 

7.2.2.8.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.322, clause 5.1.2.2.2, 

5.1.2.2.3 and 5. 1.2.2.4. 

[TS 36.322, clause 5. 1.2.2.2] 

When an UMD PDU with SN = x is received from lower layer, the receiving UM RLC entity shall: 

- if VR(UR) < X < VR(UH) and the UMD PDU with SN = x has been received before; or 

- if (VR(UH) - UM_Window_Size) <= x < VR(UR): 

- discard the received UMD PDU; 
otherwise: 

place the received UMD PDU in the reception buffer. 
[TS 36.322, clause 5. 1.2.2.3] 

When an UMD PDU with SN = x is placed in the reception buffer, the receiving UM RLC entity shall: 
if X falls outside of the reordering window: 

- update VR(UH) to x+1; 

reassemble RLC SDUs from any UMD PDUs with SN that falls outside of the reordering window, remove 
RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in sequence if not 
delivered before; 

if VR(UR) falls outside of the reordering window: 

- set VR(UR) to (VR(UH) - UM_Window_Size); 

- if the reception buffer contains an UMD PDU with SN = VR(UR): 

- update VR(UR) to the SN of the first UMD PDU with SN > current VR(UR) that has not been received; 

reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing 
so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

if T_reordering is running: 

- if VR(UX) <= VR(UR); or 

if VR(UX) falls outside of the reordering window: 
stop and reset T_reordering; 

- set VR(UX) to NULL; 

if T_reordering is not running (includes the case when T_reordering is stopped due to actions above): 
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- ifVR(UH)>VR(UR): 

start T_reordering; 
- set VR(UX) to VR(UH). 
[TS 36.322, clause 5. 1.2.2.4] 
When T_reordering expires, the receiving UM RLC entity shall: 

- update VR(UR) to the SN of the first UMD PDU with SN >= VR(UX) that has not been received; 

reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so 
and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

- if VR(UH) > VR(UR): 

start T_reordering; 

- set VR(UX) to VR(UH); 
otherwise: 

- set VR(UX) to NULL. 



7.2.2.8.3 
7.2.2.8.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 

Preamble 

UE is in state Loopback Activated (state 4) according to [18] with a RLC UM bearer as specified in table 
7.2.2.8.3.1-1. 

Table 7.2.2.8.3.1-1 : RLC parameters 



Downlink RLC 

T reordering (ms) 


FFS 



7.2.2.8.3.2 



Test procedure sequence 

Table 7.2.2.8.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: the behaviour described in table 
7.2.2.8.3.2-2 runs in parallel with steps 1 to 4 
below. 










1 


The SS transmits RLC PDU#1 containing first 
segment of RLCSDU#1. 


<— 


UMD PDU#1 


- 


- 


2 


The SS does not transmit RLC PDU#2 
containing last segment of RLC SDU#1 . 


- 


- 


- 


- 


3 


The SS transmits RLC PDU#3 containing RLC 
SDU#2. 


<~ 


UMD PDU#3 


- 


- 


4 


1 .5 * Treordering after Step 1 , the SS 
transmit RLC PDU#2 containing last segment 
ofRLCSDU#1. 


<- 


UMD PDU#2 
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Table 7.2.2.8.3.2-2: Parallel Behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


■message 


1 


The SS transmits an uplink grant allowing the 
UE to sent 2 RLC SDUs 


<- 


(UL grant) 


- 


- 


2 


Check: does the UE send back the RLC 
SDU#2? 


-> 


(RLC SDU#2) 


1 


P 



7.2.2.8.3.3 
None. 

7.2.2.9 



Specific message contents. 



UM RLC / In sequence delivery of upper layers PDUs with residual loss of 
RLC PDUs / Maximum re-ordering delay exceeds the T_reordering time 



Editor's Note: This section is based on 36.322 v8.3.0 i.e. after RAN#41. 



7.2.2.9.1 



(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE detects that RLC PDUs constructing different RLC SDUs are lost } 

then { UE delivers all received RLC SDUs to upper layer in the correct order 



7.2.2.9.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 5.1.2.2.2, 
5.1.2.2.3 and 5. 1.2.2.4. 

[TS 36.322, clause 5. 1.2.2.2] 

When an UMD PDU with SN = x is received from lower layer, the receiving UM RLC entity shall: 

- if VR(UR) < X < VR(UH) and the UMD PDU with SN = x has been received before; or 

- if (VR(UH) - UM_Window_Size) <= x < VR(UR): 

- discard the received UMD PDU; 
else: 

place the received UMD PDU in the reception buffer. 
[TS 36.322, clause 5. 1.2.2.3] 

When an UMD PDU with SN = x is placed in the reception buffer, the receiving UM RLC entity shall: 
if X falls outside of the reordering window: 

- update VR(UH) to x+ 1; 

reassemble RLC SDUs from any UMD PDUs with SN that falls outside of the reordering window, remove 
RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer in sequence if not 
delivered before; 

if VR(UR) falls outside of the reordering window: 

- set VR(UR) to (VR(UH) - UM_Window_Size); 

- if the reception buffer contains an UMD PDU with SN = VR(UR): 
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- update VR(UR) to the SN of the first UMD PDU with SN > current VR(UR) that has not been received; 

reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing 
so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

if T_reordering is running: 

- if VR(UX) <= VR(UR); or 

if VR(UX) falls outside of the reordering window and VR(UX) is not equal to VR(UH): 
stop and reset T_reordering; 

- set VR(UX) to NULL; 

if T_reordering is not running (includes the case when T_reordering is stopped due to actions above): 

- ifVR(UH)>VR(UR): 

start T_reordering; 

- set VR(UX) to VR(UH). 
[TS 36.322, clause 5. L2.2.4] 

When T_reordering expires, the receiving UM RLC entity shall: 

- update VR(UR) to the SN of the first UMD PDU with SN >= VR(UX) that has not been received; 

reassemble RLC SDUs from any UMD PDUs with SN < updated VR(UR), remove RLC headers when doing so 
and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

- ifVR(UH)>VR(UR): 

start T_reordering; 

- set VR(UX) to VR(UH); 
else: 

- set VR(UX) to NULL. 



7.2.2.9.3 


Test description 


7.2.2.9.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 




Preamble: 





UE is in state Loopback Activated (state 4) according to [18] with a RLC UM bearer as specified in table 
7.2.2.9.3.1-1. 
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Table 7.2.2.9.3.1-1 : RLC parameters 



Downlink RLC 

T reordering (ms) 


ms200 



7.2.2.9.3.2 



Test procedure sequence 



Table 7.2.2.9.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits UIVID PDU#1 containing first 
segment of RLC SDU#1. 


<- 


UMD PDU#1 


- 


- 


2 


The SS does not transmit UIVID PDU#2 
containing last segment of RLC SDU#1 . 


- 




- 


- 


3 


The SS transmits UIVID PDU#3 containing first 
segment of RLC SDU#2. 


<— 


UMD PDU#3 


- 


- 


4 


The SS transmits UMD PDU#4 containing last 
segment of RLC SDU#2. 


<— 


UMD PDU#4 


- 


- 


5 


The SS transmits UIVID PDU#5 containing first 
segment of RLC SDU#3. 


<— 


UMD PDU#5 


- 


- 


6 


The SS does not transmit UMD PDU#6 
containing last segment of RLC SDU#3. 


- 




- 


- 


7 


The SS transmits RLC UIVID #7 containing first 
segment of RLC SDU#4. 


<- 


UMD PDU#7 


- 


- 


8 


The SS transmits RLC UMD #8 containing last 
segment of RLC SDU#4. 


<- 


UMD PDU#8 


- 


- 


9 


Wait for 200 ms to ensure that T reordering for 
the UMD PDU#2 expires. 


- 


- 


- 


- 


10 


Check: Does the UE loop back the RLC 
SDU#2. 


~> 


(RLC SDU#2) 


1 


P 


11 


Wait for 200 ms to ensure that T reordering for 
the UMD PDU#6 expires. 


- 


- 


- 


- 


12 


Check: Does the UE loop back the RLC 
SDU#4. 


-> 


(RLC SDU#4) 


1 


P 



7.2.2.9.3.3 
None. 

7.2.3 
7.2.3.1 

7.2.3.1.1 

(1) 



Specific message contents 

Acknowledged Mode 

AM RLC / Concatenation and Reassembly 
Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { The UE has multiple RLC SDUs in the transmission buffer that fits into the available AMD 
PDU size } 

then { The UE concatenates the RLC SDUs in the transmission buffer into an AMD PDU and transmits 
it} 

} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { The UE receives an AMD PDUs containing concatenated RLC } 

then { The UE reassembles the RLC SDUs in accordance with the Framing Info and Length Indicators 
indicated in AMD PDUs } 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 137 ETSI TS 136 523-1 V8.0.1 (2009-01) 

Editor's note: TP should not contain "shall", should be worded as stimulus/response preferably with external 
stimulus and purely implementation information 

7.2.3.1.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.322, clauses 4.2.1.3.2 , 
4.2.1.3.3, 6.2.1.4 and 6.2.2.6. 

[TS 36.322, clause 4.2. 1.3.2] 

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall: 

- segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) 
indicated by lower layer at the particular transmission opportunity notified by lower layer. 

[TS 36.322, clause 4.2.1.3.3] 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 



reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in 
sequence. 

[TS 36.322, clause 6.2.1.4] 

AMD PDU consists of a Data field and an AMD PDU header. 

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields 
that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and 
consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and 
consists of E(s) and LI(s). 

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the 
AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an 
AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI. 



D/C 


RF 


P 


FI 


E 


SN 


SN 


Data 


... 





Oct 1 
Oct 2 
Oct 3 

Oct N 



Figure 6.2.1 .4-1 : AMD PDU (No LI) 
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Present if 
K>=3 



D/C 


RF 


P 


Fl 


E SN 


SN 


E 


Lh 




Lh 




E 


LI2 (if K>=3) 


Ll2 




E 


LIk-2 




LIk-2 




E 


LIk-1 


LIk-1 


E 


LIk 




LIk 






Padding 


Data 


... 





Oct 1 
Oct 2 
Oct 3 
Oct 4 
Oct 5 

Oct [2.5+1 .5* K- 4] 
Oct [2.5+1 .5* K- 3] 
Oct [2.5+1 .5* K- 2] 
Oct [2.5+1 .5* K-1] 
Oct [2.5+1 .5* l<] 
Oct [2.5+1 .5* K+1] 

Oct N 



Figure 6.2.1.4-2: AMD PDU (Odd number of Lis, i.e. K = 1, 3, 5, ...) 



D/C 


RF 


P 


Fl 


E 


SN 


SN 


E 


LI1 


LI1 


E 


LI2 


LI2 


... 


E 


LIk-1 


LIk-1 


E 


LIk 


LIk 


Data 


... 





Oct 1 




Oct 2 




Oct 3 




Oct 4 




Oct 5 




Oct [2+1 


5*K-2] 


Oct [2+1 


5* K-1] 


Oct [2+1 


5*K| 


Oct [2+1 


5* K+1] 



Oct N 



Figure 6.2.1.4-3: AIVID PDU (Even number of Lis, i.e. K = 2, 4, 6, ...) 

[TS 36.322, clause 6.2.2.6] 

The Fl field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. 
Specifically, the Fl field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, 
and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the Fl field 
is provided in Table 6.2.2.6-1. 
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Table 6.2.2.6-1 : Fl field interpretation 



Value 


Description 


00 


First byte of the Data field corresponds to the first byte of a RLC SDL). 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


01 


First byte of the Data field corresponds to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 


10 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


11 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 



7.2.3.1.3 


Test description 


7.2.3.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 




Preamble: 





The UE is in state Loopback Activated (state 4) according to [18] with the exceptions as listed in table 
7.2.3.1.3.1-1 and with UL RLC SDU size set to same size as received in downlink. 

Table 7.2.3.1.3.1-1: RLC settings 



Parameter 


Value 


T status prohibit 


Disabled 



7.2.3.1 .3.2 Test procedure sequence 

The SS transmits STATUS PDUs with positive acknowledgements for each received AMD PDU, 
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St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS ignores scheduling requests and does 
not allocate any uplink grant 


- 


- 


- 


- 


2 


SS transmits an AMD PDU including two RLC 
SDUs of size 40 bytes each with poll bit set to 
'1'. 


<— 


AMD PDU(AMD PDU 
header(D/C='1', RF='0', P='1', 
FI='00',E='1', SN='0',Ei='0', 
Lli='40' bytes), 2 RLC SDUs of 40 
bytes) 






3 


SS responds to any scheduling requests from 
the UE by transmitting UL grants of size 776 
bits (Note 1). 


<— 


(UL grants, 776 bits) 






4 


Check: Does UE transmit a STATUS PDU with 
positive acknowledgement? 


— > 


STATUS PDU (ACKSN=1) 


2 


P 


5 


Check: Does UE transmit two RLC SDUs 
within an AMD PDU with Fl field set to '00', 
first E field in the fixed part set to '1', first E 
field in the extension part set to '0', first LI field 
set to 40 bytes? 


— > 


AMD PDU(AMD PDU 
header(P='1', Fl='00', E='1',SN=0, 
Ei='0', Lli='40') ), two RLC SDUs 
of size 40 bytes) 


1,2 


P 


6 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


7 


SS transmits an AMD PDU including three 
RLC SDU of size 40 bytes with P field set to 
"1". 


<— 


AMD PDU(AMD PDU 
header(D/C='1', RF='0', P='1', 
FI='00',E='1', SN='1', Ei='1', 
Lli='40' bytes, Eg^'O', Ll2='40' 
bytes), three RLC SDUs of size 40 
bytes) 






8 


SS responds to any scheduling requests from 
the UE by transmitting an UL grant of size 
1096 bits. (Note 2) 


<— 


(UL grants, 1096 bits) 






9 


Check: Does UE transmits a STATUS PDU 
with positive acknowledgement? 


— > 


STATUS PDU (ACK SN=2) 


2 


P 


10 


Check: Does UE transmit three RLC SDUs 
within an AMD PDU with Fl field set to "00", 
first E field in the fixed part set to '1', first E 
field in the extension part set to '1 ', first LI field 
set to 40 bytes, second E field in the extension 
part set to '0', second LI field set to 40 bytes 
and P field set to "1"? 


— > 


AMD PDU(AMD PDU 
header(P='1', Fl='00', SN=1, 
Ei='1', Lli='40', E2='0', Ll2='40'), 
three RLC SDUs of size 40 bytes) 


1,2 


P 


Note 1 UL grant of 776 bits (/res^lS, Nprb=3, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will fit two 
RLC SDUs of 40 bytes within one AIVID PDU. MAC PDU of 776 bits=97 bytes fits an AMD PDU payload of 
80 bytes (two 40 byte RLC SDUs) + 2 byte AMD PDU header + 1 5 bytes spare for MAC header and 
possible RLC STATUS PDU and BSR report. 

Note 2 UL grant of 1096 bits {Itbs=9, Nprb=7, see TS 36.213 Table 7.1.7.2.1-1) is chosen such that UE will fit three 
RLC SDUs of 40 bytes within one AMD PDU. MAC PDU of 1096 bits=137 bytes fits an AMD PDU payload 
of 1 20 bytes (three 40 byte RLC SDUs) -i- 2 byte AMD PDU header -i- 1 5 bytes spare for MAC header and 
possible RLC STATUS PDU and BSR report. 



7.2.3.1.3.3 



None. 



Specific message contents 



7.2.3.2 AM RLC / Segmentation and Reassembly / 1 1 bit "Length Indicators" / No 

PDU segmentation 



7.2.3.2.1 

(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { the UE has a RLC SDU with larger size than available AMD PDU size in the transmission 
buffer } 

then { the UE segments the RLC SDU in accordance with the available AMD PDU size } 
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(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { the UE receives AMD PDUs containing a segmented RLC SDU } 

then { the UE reassembles the RLC SDUs in accordance with the Framing Info and Length Indicators 
indicated in the AMD PDUs } 



7.2.3.2.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.322, clauses 4.2.1.3.2, 
4.2.1.3.3 and 6,2.2.6. 

[TS 36.322, clause 4.2.1.3.2] 

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall: 

segment and/or concatenate the RLC SDUs in accordance to the TB size selected by lower layer at the particular 
transmission opportunity notified by lower layer. 

[TS 36.322, clause 4.2.1.3.3] 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 

reassemble RLC SDUs from the RLC data PDUs that are received in sequence and deliver the RLC SDUs to 
upper layer in sequence. 

[TS 36.322, clause 6.2.2.6] 

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. 
Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, 
and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field 
is provided in Table 6.2.2.6-1. 

Table 6.2.2.6-1 : FI field interpretation 



Value 


Description 


00 


First byte of the Data field corresponds to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


01 


First byte of the Data field corresponds to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 


10 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


11 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 



7.2.3.2.3 


Test description 


7.2.3.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.2.3.2.3.2 



Test procedure sequence 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 


1 


The SS ignores scheduling requests and does 
not allocate any uplinl< grant. 










2 


The SS transmits a RLC SDU of size 80 bytes 
segmented into two AMD PDUs. The two AMD 
PDUs are transmitted in separate TTIs. 


<— 


(RLCSDU#1) 

AMDPDU#1(FI='01',SN=0) 

AMDPDU#2(FI='01',SN=0) 






3 


The SS responds to any scheduling requests 
from the UE by transmitting an UL grant of size 
392 bits. (Note 1). 


<— 


(UL grants) 






4 


Check: Does the UE return a RLC SDU with 
equal content as sent in downlink in step 2 
segmented into two AMD PDUs and received 
in different TTIs? 


— > 


(RLCSDU#1) 
AMD PDU#1 
AMD PDU#2 


1,2 


P 


5 


The SS ignores scheduling requests and does 
not allocate any uplink grant. 


- 


- 


- 


- 


6 


The SS sends a RLC SDU of size 120 bytes 
octets segmented into three AMD PDUs. 


<— 


(RLC SDU#2) 

AMDPDU#1(FI='01',SN=2) 
AMDPDU#2(FI='11',SN=3) 
AMDPDU#3(FI='10',SN=4) 






7 


The SS responds to any scheduling requests 
from the UE by transmitting an UL grant of size 
392 bits. (Note 1). 


<-- 


(UL grants) 






8 


Check: Does the UE return a RLC SDU with 
equal content as sent in downlink in step 6 
segmented into three AMD PDUs where each 
AMD PDU is received in different TTI? 


— > 


(RLC SDU#2) 
AMD PDU#1 
AMD PDU#2 
AMD PDU#3 


1,2 


P 


Note 1 UL grant of 392 bits (Itbs=8, Nprb=3, see TS 36.213 Table 7.1 .7.2.1-1) is cliosen to force tine UE to 

segment tine returned UL RLC SDU into multiple AMD PDUs. An UL grant of 392 bits=49 bytes allows tlie 
UE to transmit one AMD PDU of maximum 46 bytes (49 bytes - 2 byte AMD PDU header - minimum 1 byte 
MAC lieader). 



7.2.3.2.3.3 
None. 



Specific message contents 



7.2.3.3 AM RLC / Segmentation and Reassembly / 1 1 -bit "Length Indicators" 

/"Framing Info Field" 



Editor's Note; This section is based on 36.322 v8.3.0 i.e. after RAN#41. 



7.2.3.3.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 
then { UE correctly decodes the received AMD PDU or AMD PDU segment } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 01 
then { UE correctly decodes the received AMD PDU or AMD PDU segment } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 11 
then { UE correctly decodes the received AMD PDU or AMD PDU segment} 
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(4) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment containing a FI field set to 10 
then { UE correctly decodes the received AMD PDU or AMD PDU segment } 



7.2.3.3.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 6.2.2.6. 

[TS 36.322, clause 6.2.2.6] 

Length: 2 bits. 

The FI field indicates whether a RLC SDU is segmented at the beginning and/or at the end of the Data field. 
Specifically, the FI field indicates whether the first byte of the Data field corresponds to the first byte of a RLC SDU, 
and whether the last byte of the Data field corresponds to the last byte of a RLC SDU. The interpretation of the FI field 
is provided in Table 6.2.2.6-1. 



Table 6.2.2.6-1 : FI field interpretation 



Value 


Description 


00 


First byte of the Data field corresponds to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


01 


First byte of the Data field corresponds to the first byte of a RLC SDU. 

Last byte of the Data field does not correspond to the last byte of a RLC SDU. 


10 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field corresponds to the last byte of a RLC SDU. 


11 


First byte of the Data field does not correspond to the first byte of a RLC SDU. 
Last byte of the Data field does not correspond to the last byte of a RLC SDU. 



7.2.3.3.3 


Test description 


7.2.3.3.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.2.3.3.3.2 



Test procedure sequence 



Table 7.2.3.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits AMD PDU#1 containing a 
complete RLC SDU#1 (Fl field = 00). 


<- 


AMD PDU#1 


- 


- 


2 


Check: Does the UE transmit RLC SDU#1 ? 


— > 


(RLCSDU#1) 


1 


P 


3 


The SS transmits AMD PDU#2 containing the 
first segment of RLC SDU#2 (Fl field = 01 ). 


<— 


AMD PDU#2 


- 


- 


4 


The SS transmits AMD PDU#3 containing the 
second segment of RLC SDU#2 (Fl field = 11). 


<- 


AMD PDU#3 


- 


- 


5 


The SS transmits AMD PDU#4 containing the 
last segment of RLC SDU#2 (Fl field = 1 0). 


<- 


AMD PDU#4 


- 


- 


6 


Check: Does the UE transmit RLC SDU#2? 


-> 


(RLC SDU#2) 


2,3, 
4 


P 


7 


The T_poll_retransmit timer for RLC PDU#5 
expires and SS assumes that the transmission 
of AMD PDU#5 containing a complete RLC 
SDU#3 and a complete RLC SDU#4 is failed 
and consider RLC PDU#5 for re-transmission 










8 


The SS transmits AMD PDU segment 
containing a complete RLC SDU#3 (Fl field = 
GO). 


<- 


AMD PDU segment 






9 


Check: Does the UE transmit RLC SDU#3? 


— > 


(RLC SDU#3) 


1 


P 


10 


The SS transmits AMD PDU segment 
containing the first segment of RLC SDU#4 (Fl 
field = 01). 


<— 


AMD PDU segment 






11 


The SS transmits AMD PDU segment 
containing the second segment of RLC SDU#4 
(Fl field = 11). 


<- 


AMD PDU segment 






12 


The SS transmits AMD PDU segment 
containing the last segment of RLC SDU#4 (Fl 
field = 10). 


<- 


AMD PDU segment 






13 


Check: Does the UE transmit RLC SDU#4? 


-> 


(RLC SDU#4) 


2,3, 
4 


P 



7.2.3.3.3.3 
None. 



Specific message contents 



7.2.3.4 AM RLC / Segmentation and Reassembly / 1 1 -bit "Length Indicators" / 

Different numbers of Length Indicators 



Editor's Note: This section is based on 36.322 v8.2.0 i.e. after RAN#40. 



7.2.3.4.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment without no LI field } 
then { UE correctly decodes the received AMD PDU or AMD PDU segment } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment with one LI field } 
then { UE correctly decodes the received AMD PDU or AMD PDU segment } 
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(3) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU or an AMD PDU segment with two LI fields } 
then { UE correctly decodes the received AMD PDU or AMD PDU segment } 
} 

7.2.3.4.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.322, clause 6.2.2.5. 

[TS 36.322, clause 6.2.2.5] 

Length: 1 1 bits. 

The LI field indicates the length in bytes of the corresponding Data field element present in the AMD PDU. The first LI 
present in the AMD PDU header corresponds to the first Data field element present in the Data field of the AMD PDU, 
the second LI present in the AMD PDU header corresponds to the second Data field element present in the Data of the 
AMD PDU, and so on. 



Test description 
Pre-test conditions 



7.2.3.4.3 




7.2.3.4.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in Loopback Activated state (state 4) according to [18]. 
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7.2.3.4.3.2 



Test procedure sequence 



Table 7.2.3.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits AMD PDU#1 containing a 
complete RLC SDU#1 without LI field. 


<— 


AMD PDU#1 


1 


- 


2 


The SS transmits an uplink grant allowing the 
UE to transmit 1 RLC SDU. 


<— 


(UL grant) 


1 


- 


3 


Check: Does the UE transmit RLC SDU#1? 


— > 


{RLCSDU#1) 


1 


P 


4 


The SS transmits AIVID PDU#2 containing a 
complete RLC SDU#2 and a complete RLC 
SDU#3 with one LI field. 


<— 


AMD PDU#2 


2 




5 


The SS transmits two uplink grants allowing 
the UE to transmit 2 RLC SDUs. 


<— 


(UL grant) 


2 


- 


6 


Check: Does the UE transmit RLC SDU#2? 


— > 


(RLC SDU#2) 


2 


P 


7 


Check: Does the UE transmit RLC SDU#3? 


— > 


(RLC SDU#3) 


2 


P 


8 


The SS transmits AIVID PDU#3 containing a 
complete RLC SDU#4, a complete RLC 
SDU#5 and a complete RLC SDU#6 with two 
LI fields. 


<— 


AMD PDU#3 


3 




9 


The SS transmits three uplink grants allowing 
the UE to transmit 3 RLC SDUs. 


<— 


(UL grant) 


3 


- 


10 


Check: Does the UE transmit RLC SDU#4? 


— > 


(RLC SDU#4) 


3 


P 


11 


Check: Does the UE transmit RLC SDU#5? 


— > 


(RLC SDU#5) 


3 


P 


12 


Check: Does the UE transmit RLC SDU#6? 


— > 


(RLC SDU#6) 


3 


P 


13 


The T_poll_retransmit timer for RLC PDU#5 
expires and SS assumes that the transmission 
of AIVID PDU#5 containing a complete RLC 
SDU#7, a complete RLC SDU#8, a complete 
RLC SDU#9, a complete RLC SDU#10, a 
complete RLC SDU#1 1 and a complete RLC 
SDU#12 is failed and consider RLC PDU#5 for 
re-transmission. 










14 


The SS transmits AMD PDU segment 
containing a complete RLC SDU#7 without LI 
field. 


<— 


AMD PDU segment 


1 




15 


The SS transmits an uplink grant allowing the 
UE to transmit 1 RLC SDU. 


<— 


(UL grant) 


1 


- 


16 


Check: Does the UE transmit RLC SDU#7? 


— > 


(RLC SDU#7) 


1 


P 


17 


The SS transmits AMD PDU segment 
containing a complete RLC SDU#8 and a 
complete RLC SDU#9 with one LI field. 


<— 


AMD PDU segment 


2 




18 


The SS transmits two uplink grants allowing 
the UE to transmit 2 RLC SDUs. 


<— 


(UL grant) 


2 


- 


19 


Check: Does the UE transmit RLC SDU#8? 


— > 


(RLC SDU#8) 


2 


P 


20 


Check: Does the UE transmit RLC SDU#9? 


— > 


(RLC SDU#9) 


2 


P 


21 


The SS transmits AMD PDU segment 
containing a complete RLC SDU#10, a 
complete RLC SDU#1 1 and a complete RLC 
SDU#1 2 with two LI fields. 


<— 


AMD PDU segment 


3 




22 


The SS transmits three uplink grants allowing 
the UE to transmit 3 RLC SDUs. 


<— 


(UL grant) 


3 


- 


23 


Check: Does the UE transmit RLC SDU#10? 


-> 


(RLCSDU#10) 


3 


P 


24 


Check: Does the UE transmit RLC SDU#1 1 ? 


-> 


(RLCSDU#11) 


3 


P 


25 


Check: Does the UE transmit RLC SDU#12? 


-> 


(RLCSDU#12) 


3 


P 



Editor's note: step 13 should be checked, there could be a mismatch between DL AMD PDU numbers. 
Editor's note: how to allocate "sufficient grants" is FFS for the time being. 



7.2.3.4.3.3 
None. 



Specific message contents 
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7.2.3.5 AM RLC / Reassembly / 1 1 -bit "Length Indicators" / LI value > PDU size 

7.2.3.5.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives PDU with "Length Indicators" that point beyond the end of the PDU } 
then { UE discards PDU } 
} 

7.2.3.5.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.5.1 
and 6.2.2.5. 

[TS 36.322, clause 5.5.1] 

When an RLC entity receives an RLC PDU that contains reserved or invalid values, the RLC entity shall: 

discard the received PDU.[TS 36.322, clause 6.2.2.5] 

Length: 1 1 bits. 

The LI field indicates the length in bytes of the corresponding Data field element present in the AMD PDU. The first LI 
present in the AMD PDU header corresponds to the first Data field element present in the Data field of the AMD PDU, 
the second LI present in the AMD PDU header corresponds to the second Data field element present in the Data of the 
AMD PDU, and so on. 

Test description 

Pre-test conditions 



7.2.3.5.3 




7.2.3.5.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in Loopback Activated state (state 4) according to [18] with the loopback size set to 102 bytes. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



148 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



7.2.3.5.3.2 



Test procedure sequence 



Table 7.2.3.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 


1 


The SS transmits an AMD PDU of 50 data 
bytes to the UE. This PDU is the I'" part of 
SDU#1. 


<— 


AMDPDU#1(SN = 0) 






2 


The SS transmits an AIVID PDU of 100 data 
bytes to the UE. This PDU contains the last 
part of SDU#1 , and the 1" part of SDU#2. LI 
associated with PDU#2 has a value > PDU 
size, i.e. > 100. 


<— 


AMDPDU#2(SN=1) 






3 


The SS transmits an AMD PDU of 100 data 
bytes to the UE. This PDU contains the last 
part of SDU 2, and the l" part of SDU#3. 


<— 


AMD PDU#3(SN=2) 






4 


The SS transmits an AMD PDU of 50 data 
bytes to the UE. This PDU contains the last 
part of SDU#3. 


<— 


AMD PDU#4(SN=3) 






5 


Check: Does the UE transmit a STATUS PDU 
with NACK SN field set to 1 ? 


— > 


STATUS PDU 


1 


P 


6 


The SS transmits an AMD PDU of 100 data 
bytes to the UE. This PDU contains the last 
part of SDU#1 , and the 1st part of SDU#2. The 
LI is correct. 


<— 


AMDPDU#2(SN=1) 






7 


Check: Does the UE transmit RLC SDU#1 ? 


— > 


(RLCSDU#1) 


1 


P 


8 


Check: Does the UE transmit RLC SDU#2? 


— > 


(RLC SDU#2) 


1 


P 


9 


Check: Does the UE transmit RLC SDU#3? 


— > 


(RLC SDU#3) 


1 


P 



7.2.3.5.3.3 



Specific message contents 



None. 



7.2.3.6 



AM RLC / Correct use of Sequence Numbering 



7.2.3.6.1 



Test Purpose (TP) 



(1) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE transmits the first PDU } 

then { UE sets the Sequence Number field equal to 



(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE transmits subsequent PDUs } 

then { SN incremented by 1 for each PDU transmitted 



(3) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE transmits more than 1024 PDUs } 

then { UE wraps the Sequence Number after transmitting the 1024 PDU 
} 

(4) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { more than 1024 PDUs are sent to UE } 

then { UE accepts PDUs with SNs that wrap around every 1024 PDU } 
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7.2.3.6.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 
5.1.3.1.1, 6.2.2.3 and 7.1. 

[TS 36.322, clause 5.1.3.1.1] 



The transmitting side of an AM RLC entity shall prioritize transmission of RLC control PDUs over RLC data PDUs. 
The transmitting side of an AM RLC entity shall prioritize retransmission of RLC data PDUs over transmission of new 
AMD PDUs. 

The transmitting side of an AM RLC entity shall maintain a transmitting window according to state variables VT(A) 
and VT(MS) as follows: 

- a SN falls within the transmitting window if VT(A) <= SN < VT(MS); 

a SN falls outside of the transmitting window otherwise. 

The transmitting side of an AM RLC entity shall not deliver to lower layer any RLC data PDU whose SN falls outside 
of the transmitting window. 

When delivering a new AMD PDU to lower layer, the transmitting side of an AM RLC entity shall: 

- set the SN of the AMD PDU to VT(S), and then increment VT(S) by one. 

The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful 
reception by its peer AM RLC entity) for a RLC data PDU by the following: 

- STATUS PDU from its peer AM RLC entity. 

When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC 
entity shall: 

if positive acknowledgements have been received for all other AMD PDUs whose SN fall within the range 
VT(A) <= SN < VT(S): 

- set VT(A) equal to VT(S); 
else 

- set VT(A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT(A) 
<= SN < VT(S) and for which a positive acknowledgment has not been received yet. 

if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU: 

- send an indication to the upper layers of successful delivery of the RLC SDU.... 



[TS 36.322, clause 6.2.2.3] 

Length: lObits for AMD PDU, AMD PDU segments and STATUS PDUs. ... 

The SN field indicates the sequence number of the corresponding ... AMD PDU. For an AMD PDU segment, the SN 
field indicates the sequence number of the original AMD PDU from which the AMD PDU segment was constructed 
from. The sequence number is incremented by one for every ... AMD PDU. 

[TS 36.322, clause 7.1] 



All state variables (i.e. VT(A), VT(MS), VT(S), VR(R), VR(MR), VR(X), VR(MS), VR(H), VT(US), VR(UR), 
VR(UX) and VR(UH)) are non-negative integers. 
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All state variables related to AM data transfer (i.e. VT(A), VT(MS), VT(S), VR(R), VR(MR), VR(X), VR(MS) and 
VR(H)) can take values from to 1023. All arithmetic operations contained in the present document on state variables 
related to AM data transfer are affected by the AM modulus (i.e. final value = [value from arithmetic operation] modulo 
1024). 

AMD PDUs ... are numbered integer sequence numbers (SN) cycling through the field: to 1023 for AMD PDU ... 



c) VT(S) - Send state variable 

This state variable holds the value of the SN to be assigned for the next newly generated AMD PDU, and it serves as 
the higher edge of the STATUS receiving window. It is initially set to 0, and is updated whenever the AM RLC entity 
deUvers an AMD PDU with SN = VT(S). 



7.2.3.6.3 


Test description 


7.2.3.6.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in Loopback Activated state (state 4) according to [18]. 



7.2.3.6.3.2 



Test procedure sequence 



Table 7.2.3.6.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage/PDU/SDU 


- 


EXCEPTION: Step 1 to 2 are executed 1024 
times. 


- 


- 


- 


- 




EXCEPTION: In parallel to step 1 , the 
behaviour described in table 7.2.3.6.3.2-2 is 
running. 










1 


The SS transmits an AMD PDU to the UE. 
SN equals and is incremented for each PDU 
transmitted. Polling bit enabled for every 128th 
AMD PDU transmitted. 


<— 


AMD PDU 






2 


The UE transmits a STATUS PDU with 

ACK_SN field which is smaller 

or equal to last SN transmitted from the SS 

and greater than 128 resp 

multiples of 128. 


— > 


STATUS PDU 






3 


The SS transmits an AMD PDU to the UE. SN 
equals 0. The polling bit is enabled. 


<— 


AMD PDU 


- 


- 


4 


Check: Does the UE transmit a STATUS PDU 
withACK SN = 1? 


— > 


STATUS PDU 


4 


P 


5 


Check: Does the UE transmit an AMD PDU 
with SN=0? 


— > 


AMD PDU 


3 


P 


6 


The SS transmits a STATUS PDU with 
ACK SN = 1. 


<— 


STATUS PDU 


- 


- 
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Table 7.2.3.6.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Check: does the UE transmit an AMD PDU 
with SN = 0? 


— > 


AMD PDU 


1 


P 


- 


EXCEPTION: Steps 2-3 are executed 1023 
times. 


- 


- 


- 


- 


2 


Checl<: does the UE transmit an AMD PDU 
with SN increased by 1 compared with the 
previous one? 


--> 


AMD PDU 


2 


P 


3 


IF the AMD PDU received in step 2 contains a 
polling bit THEN the SS transmits a STATUS 
PDU with ACK_SN acknowledging all the AMD 
PDUs received. 


<— 


STATUS PDU 







7.2.3.6.3.3 
None. 



Specific message contents 



7.2.3.7 



AM RLC / Control of Transmit Window 



7.2.3.7.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state with DRB established and pending uplink data for 

transmission} 

ensure that { 

when { AMD PDUs in transmission buffer fall outside VT{A) <= SN < VT{MS) } 
then { UE does not transmit these AMD PDUs } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state with DRB established and pending uplink data for 
transmission } 
ensure that { 

when { receiving a STATUS PDU where ACK_SN acknowledges at least one AMD PDU not yet acknowledged 

} 

then { UE transmits AMD PDUs within updated window range} 



7.2.3.7.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 
5.1.3.1.1 and, 7.17.2. 

[TS 36.322, clause 5.1.3.1.1] 



The transmitting side of an AM RLC entity shall maintain a transmitting window according to state variables VT(A) 
and VT(MS) as follows: 

- a SN falls within the transmitting window if VT(A) <= SN < VT(MS); 

a SN falls outside of the transmitting window otherwise. 

The transmitting side of an AM RLC entity shall not deliver to lower layer any RLC data PDU whose SN falls outside 
of the transmitting window. 

When delivering a new AMD PDU to lower layer, the transmitting side of an AM RLC entity shall: 

- set the SN of the AMD PDU to VT(S), and then increment VT(S) by one. 
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The transmitting side of an AM RLC entity can receive a positive acknowledgement (confirmation of successful 
reception by its peer AM RLC entity) for a RLC data PDU by the following: 

- STATUS PDU from its peer AM RLC entity. 

When receiving a positive acknowledgement for an AMD PDU with SN = VT(A), the transmitting side of an AM RLC 
entity shall: 

if positive acknowledgements have been received for all other AMD PDUs whose SN fall within the range 
VT(A) <= SN < VT(S): 

- set VT(A) equal to VT(S); 
else 

- set VT(A) equal to the SN of the AMD PDU with the smallest SN, whose SN falls within the range VT(A) 
<= SN < VT(S) and for which a positive acknowledgment has not been received yet. 

if positive acknowledgements have been received for all AMD PDUs associated with a transmitted RLC SDU: 

send an indication to the upper layers of successful delivery of the RLC SDU. 

[TS 36.322, clause 7.2] 

a) AM_Window_Size 

This constant is used by both the transmitting side and the receiving side of each AM RLC entity to calculate VT(MS) 
from VT(A), and VR(MR) from VR(R). AM_Window_Size = 512. 



[TS 36.322 ver 8.2.0 clause 7.1] 

a) VT(A) - Acknowledgement state variable 

This state variable holds the value of the SN of the next AMD PDU for which a positive acknowledgment is to be 
received in-sequence, and it serves as the lower edge of the transmitting window). It is initially set to 0, and is updated 
whenever the AM RLC entity receives a positive acknowledgment for an AMD PDU with SN = VT(A). 

b) VT(MS) - Maximum send state variable 

This state variable equals VT(A) + AM_Window_Size, and it serves as the higher edge of the transmitting window. 



7.2.3.7.3 


Test description 


7.2.3.7.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in Loopback Activated state (state 4) according to [18] with the loopback size set to 100 bytes. 
- UE support for either RLC SDU Buffering OR RLC SDU Discard. This is to be indicated in the PIXIT. 
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7.2.3.7.3.2 



Test procedure sequence 



Table 7.2.3.7.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


- 


EXCEPTION: Step 1 is repeated W+1 times, 
where \N = AM Window Size. 


- 


- 


- 


- 




EXCEPTION: In parallel to step 1 , the 
behaviour described in table 7.2.3.7.3.2-2 is 
running.. 










1 


The SS transmits an AIVID PDU containing a 
SDUtotheUE 


<— 


AMD PDU 






2 


Check: does the UE transmit an AIVID PDU 
within t poll retransmit/2? 


— > 


AMD PDU 


1 


F 


3 


The SS transmits a STATUS PDU to 
acknowledge the W uplink AIVID PDUs with 
SN=0 to SN=W-1 . ACK SN = W. 


<— 


STATUS PDU 






- 


EXCEPTION: Step 4 is repeated W+1 times. 


- 


- 


- 


- 




EXCEPTION: IF UE buffers RLC SDUs in 
parallel to the events described in Step 4 the 
steps specified in table 7.2.3.7.3.2-3 shall take 
place; IF UE discards RLC SDUs in parallel to 
the events described in Step 4 the steps 
specified in table 7.2.3.7.3.2-4 shall take place. 










4 


The SS transmits an AIVID PDU containing a 
SDUtotheUE 


<— 


AMD PDU 


- 


- 


5 


Check: does the UE transmit an AIVID PDU 
within t poll retransmit/2? 


— > 


AMD PDU 


1 


F 


6 


The SS transmits a STATUS PDU to 
acknowledge W uplink RLC PDUs 


<— 


STATUS PDU 


- 


- 


7a 


IF UE buffers RLC SDUs THEN Check: does 
the UE transmit the same PDU content as 
received in the corresponding downlink PDU 
(2W+1)oftheSDU? 


— > 


AMDPDU2W+1(SN=0) 


2 


P 


7b1 


IF UE discards RLC SDUs THEN The SS 
transmits an AIVID PDU containing an SDU to 
theUE 


— > 


AMD PDU W+2, Poll 






7b2 


Check: does the UE transmit the same AIVID 
PDU content as received in the corresponding 
downlink AMD PDU (2W+3) of the SDU? 


— > 


AMD PDU 2W+3, (SN = 0) 


2 


P 


Note: SDUs are numbered 1,2, ..., 2W+3 



Table 7.2.3.7.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


- 


EXCEPTION: Step 1 is repeated W-1 times. 


- 


- 


- 


- 


1 


The UE transmit an AMD PDU with the same 
data as received in the corresponding DL AMD 
PDU. 


— > 


AMD PDU 






2 


Check: does the UE transmit an AMD PDU 
with the Poll bit set and with the contents of the 
SDU? 


— > 


AMDPDU(SN=W-1), Poll 


1 


P 
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Table 7.2.3.7.3.2-3: Parallel behaviour 



St 


Procedure 


■message Sequence 


TP 


Verdict 


U-S 


■message 


- 


EXCEPTION: Step 1 is repeated W-1 times. 


- 


- 


- 


- 


1 


The UE transmit an AIVID PDU with the same 
data as received in the corresponding DL AMD 
PDU. 


— > 


AMD PDU 






2 


The UE transmit an AMD PDU with the Poll bit 
set. and contents of the {2W)th SDU. The 
contents is that of the (2W)th SDU. 


--> 


AMDPDU(SN=2W-1), Poll 







Table 7.2.3.7.3.2-4: Parallel behaviour 



St 


Procedure 


■\1essage Sequence 


TP 


Verdict 


U-S 


■message/PDU/SDU 


- 


EXCEPTION: Step 1 is repeated W-1 times. 


- 


- 


- 


- 


1 


The UE transmits an AMD PDU with the same 
data as received in the corresponding DL AMD 
PDU. 


— > 


AMD PDU W 






2 


The UE transmit an AMD PDU with the Poll bit 
set. The contents is that of the (2W+1)th SDU. 


--> 


AMDPDU(SN=2W-1), Poll 


- 


- 



7.2.3.7.3.3 
None. 



Specific message contents 



7.2.3.8 
7.2.3.8.1 

(1) 



AM RLC / Control of Receive Window 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { the UE receives AMD PDUs with SN outside the upper boundary of the receive window 
then { the UE discards these AMD PDUs } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { the receive window has been moved } 

then { UE continues accepting AMD PDUs within updated window range } 



7.2.3.8.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 
5.1.3.2.1., and 7.2.. 

[TS 36.322, clause 5.1.3.2.1] 



The receiving side of an AM RLC entity shall maintain a receiving window according to state variables VR(R) and 
VR(MR) as follows: 

- a SN falls within the receiving window if VR(R) <= SN < VR(MR); 

a SN falls outside of the receiving window otherwise. 

When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity shall: 
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either discard the received RLC data PDU or place it in the reception buffer (see sub clause 5.1.3.2.2); 

if the received RLC data PDU was placed in the reception buffer: 

update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop T_reordering as 
needed (see sub clause 5.1.3.2.3). 

When T_reordering expires, the receiving side of an AM RLC entity shall: 

update state variables and start T_reordering as needed (see sub clause 5.1.3.2.4). 

[TS 36.322, clause 7.2] 

a) AM_Window_Size 

This constant is used by both the transmitting side and the receiving side of each AM RLC entity to calculate VT(MS) 
from VT(A), and VR(MR) from VR(R). AM_Window_Size = 512. 



7.2.3.8.3 


Test description 


7.2.3.8.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 
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7.2.3.8.3.2 



Test procedure sequence 



Table 7.2.3.8.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 




EXCEPTION: Step 1 shall be repeated W 
times, where W is AlVI Window Size. Polling 
bit enabled for the Wth RLC PDU transmitted. 
The SS shall set the Sequence Number field 
for the first AMD PDU to and increment it by 
1 for every execution of Step 1 . 










1 


The SS transmits an AMD PDU to the UE 


<— 


AMD PDU 






2 


Check: does the UE transmit a STATUS PDU 
acknowledging W PDUs? (ACK SN = W) 


— > 


STATUS PDU 


1 


P 


3 


The SS transmits the {W+1)th AMD PDU to 
the UE with the Sequence Number field set to 
((2W mod 1024) = 0) and the Polling bit set 


<— 


AMD PDU 






4 


Check: does the UE transmit a STATUS PDU 
acknowledging W PDUs? (ACK SN = W) 
(Note1) 


— > 


STATUS PDU 


1 


P 


5 


The SS transmits the {W+2)th AMD PDU to 
the UE with the Sequence Number field set to 
W and the Polling bit set. 


<— 


AMD PDU 






6 


Check: does the UE transmit a STATUS PDU 
acknowledging W +1 PDUs? (ACK SN field = 
W+1)(Note2) 


— > 


STATUS PDU 


2 


P 


Note 1 : This shows that the UE has discarded the (W+1)th PDU. 

Note 2: This shows that the UE did not discard the (W+2)th PDU and has updated the Receive Window correctly 



7.2.3.8.3.3 
None. 



Specific message contents 



7.2.3.9 



AM RLC / Polling for status 



7.2.3.9.1 

(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state and using AM RLC 
ensure that { 

when { last data in the buffer was transmitted } 
then { UE transmits a Poll } 



(2) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC 
ensure that { 

when { the poll retransmit timer expires } 
then { UE transmits a Poll } 



} 



(3) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC 
ensure that { 

when { PDU_WITHOUT_POLL = Poll_PDU } 
then { UE transmits a Poll } 
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(4) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { BYTE_WITHOUT_POLL=Poll_Byte } 
then { UE transmits a Poll } 

} 

7.2.3.9.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 5.2.2. 

[TS 36.322, clause 5.2.2] 

Upon assembly of a new AMD PDU, the transmitting side of an AM RLC entity shall: 

- increment PDU_WITHOUT_POLL by one; 

increment B YTE_WITHOUT_POLL by every new byte of Data field element that it maps to the Data field of 
the RLC data PDU; 

- if PDU_WITHOUT_POLL >= Poll_PDU; or 

- if BYTE_WITHOUT_POLL >= Poll_Byte; 

include a poll in the RLC data PDU as described below. 

Upon assembly of a AMD PDU or AMD PDU segment, the transmitting side of an AM RLC entity shall: 

if both the transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC data 
PDU awaiting for acknowledgements) after the transmission of the RLC data PDU; or 

if no further RLC data PDU can be transmitted after the transmission of the RLC data PDU (e.g. due to window 
stalling); 

include a poll in the RLC data PDU as described below. 

To include a poll in a RLC data PDU, the transmitting side of an AM RLC entity shall: 

- set the P field of the RLC data PDU to " 1 " ; 

- set PDU_WITHOUT_POLL to 0; 

- set BYTE_WITHOUT_POLL to 0; 

- set POLL_SN to VT(S) - 1 ; 

if T_poll_retransmit is not running: 

start T_poll_retransmit; 

else: 

restart T_poll_retransmit; 

[TS 36.322, clause 5.2.2.3] 

Upon expiry of T_poll_retransmit, the transmitting side of an AM RLC entity shall: 

if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC data PDU 
awaiting for acknowledgements); or 

if no new RLC data PDU can be transmitted (e.g. due to window stalling): 

- consider the AMD PDU with SN = VT(S) - 1 for retransmission; 

include a poll in a RLC data PDU as described in section 5.2.2. L 
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7.2.3.9.3 


Test description 


7.2.3.9.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 




Preamble: 





UE is in state Loopback Activated (state 4) according to [18] with 1 RLC AM DRB configured (called DRBl) 
according to table 7.2.3.9.3.1-1. 

Table 7.2.3.9.3.1-1 : RLC Settings 



Parameter 


Value 


Poll PDU 


256 


Poll Byte 


25 KBytes 


T poll retransmit 


400ms 



Note: these settings assume a 2-octet RLC header and 2-octets MAC header for non-segmented RLC SDUs. 
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7.2.3.9.3.2 



Test procedure sequence 



Table 7.2.3.9.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




During the whole test sequence, the size of the 
UL grants allocated by the SS shall be 12 576 
bits. (Note 1) 












EXCEPTION: In parallel to the events 
described in step 1, the steps specified in 
Table 7.2.3.9.3.2-2 should take place 










1 


The SS transmits 4 AMD PDUs, each 
containing an RLC SDU of size 12 544 bits., 
on DRB1. 


<— 


AMD PDU(SN=0) 
AMDPDU{SN=1) 
AMD PDU{SN=2) 
AMD PDU{SN=3) 






2 


Checkl : does the UE transmit an AMD PDU 
with SN=3 and P=1? 


— > 


AMD PDU 


2 


P 


3 


Upon receiving the Poll, the SS sends an RLC 
Status Report. 


<— 


STATUS PDU 


- 


- 


4 


Check: does the UE retransmit an AMD PDU 
within T poll retransmit ms ? 


-> 


AMD PDU 


2 


F 


5 


SS performs a RRC Connection 
Reconfiguration procedure triggering an RLC- 
reestablishment of the RLC entity and sets 
Poll PDU to 4. 












EXCEPTION: In parallel to the events 
described in step 6, the steps specified in 
Table 7.2.3.9.3.2-3 should take place 










6 


The SS transmits 8 AMD PDUs, each 
containing an RLC SDU of 12 544bits on 
DRB1. 


<— 


AMD PDU(SN=0) 
AMDPDU{SN=1) 

AMD PDU(SN=7) 






7 


The SS sends a Status Report with 

NACK SN=0, NACK SN=1 , MACK SN=2 and 

NACK SN=4. 


<— 


STATUS PDU 






8 


Check: does the UE transmit AMD PDUs with 

the following SN and P values: 

AMD PDU, SN=0, P=0 

AMDPDU, SN=1, P=0 

AMD PDU, SN=2, P=0 

AMD PDU, SN=4, P=0 


— > 


AMD PDU{SN=0, P=0) 
AMDPDU{SN=1, P=0) 
AMD PDU{SN=2, P=0) 
AMD PDU{SN=4, P=0) 


3 


P 


9 


SS performs a RRC Connection 
Reconfiguration procedure triggering an RLC- 
reestablishment of the RLC entity and sets 
Poll PDU to 256. 












EXCEPTION: In parallel to the events 
described in step 10, the steps specified in 
Table 7.2.3.9.3.2-4 should take place 










12 


The SS transmits 34 AMD PDUs, each 
containing an RLC SDU of size 12 544 bits on 
DRB1. 


<— 


AMD PDU(SN=0) 
AMDPDU{SN=1) 

AMD PDU(SN=33) 






Note 1 UL grant of 12 576 bits (/tss=25, Nprb=20, see TS 36.213 Table 7.1.7.2.1-1) is chosen to allow the UE to 
loop back one SDU of size 12 544 bits into each AIVID PDU sent in the uplink (12 576 bits - 16 bit AMD 
PDU header - 1 6 bit MAC SDU header). 



Table 7.2.3.9.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Check: Does the UE transmit 4 AMD PDUs, 
with only the last one having the poll bit set? 
Record time Ta when the PDU with the poll bit 
set is received at SS. 


— > 


AMD PDUs 


1 


P 
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Table 7.2.3.9.3.2-3: Parallel behaviour 



St 


Procedure 


■message Sequence 


TP 


Verdict 




U-S 


■message 


1 


Check: Does the UE transmit 8 AMD PDUs, 
with the poll bit set only in the 4* and the 8* 
PDUs? 


— > 


AMD PDUs 


3 


P 



Table 7.2.3.9.3.2-4: Parallel behaviour 



St 


Procedure 


■\1essage Sequence 


TP 


Verdict 




U-S 


■\1essage 


1 


Check: Does the UE transmit 34 AMD PDUs, 
with the poll bit set only in the 16* one, the 
32"'' one and the last one? 


— > 


AMD PDUs 


4 


P 



7.2.3.9.3.3 
None. 



Specific message contents 



7.2.3.1 AM RLC / Receiver Status Triggers 

Editor's note: this test case description is not based on 36.322 v8.3.0. 
7.2.3.10.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { Reception failure of an RLC data PDU is detected } 
then { UE initiates Status Reporting when T_reordering expires } 

} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { Status Reporting is triggered and T_status_prohibit_timer is running} 
then { UE wait until T_prohibit_timer has expired to send Status Report } 

} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { Polling from peer AM RLC entity is detected } 
then { UE initiates Status Reporting } 



7.2.3.10.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2.3. 

[TS 36.322, clause 5.2.3] 

An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative 
acknowledgements of RLC PDUs (or portions of them). 

RRC configures whether or not the status prohibit function is to be used an AM RLC entity. 

Triggers to initiate STATUS reporting include: 
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Polling from its peer AM RLC entity: 

When a RLC data PDU with SN = x and the P field set to " 1 " is received from lower layer, the receiving side 
of an AM RLC entity shall: 

if the PDU is to be discarded as specified in subclause 5.L3.2.2; or 

- ifx<VR(MS): 

- trigger a STATUS report; 

else: 

- delay triggering the STATUS report until x < VR(MS). 

NOTE: This ensures that the RLC Status report is transmitted after HARQ reordering. 

Detection of reception failure of an RLC data PDU: 

The receiving side of an AM RLC entity shall trigger a STATUS report when T_reordering expires. 

NOTE: The expiry of T_reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, 
but the STATUS report shall be triggered after VR(MS) is updated. 

When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall: 

if T_status_prohibit is not running: 

at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and deliver it to 
lower layer; 

else: 

at the first transmission opportunity indicated by lower layer after T_status_prohibit expires, construct a 
STATUS PDU even if status reporting was triggered several times while T_status_prohibit was running and 
deliver it to lower layer; 

When a STATUS PDU has been delivered to lower layer, the receiving side of an AM RLC entity shall: 

start T_status_prohibit. 

When constructing a STATUS PDU, the AM RLC entity shall: 

- for the AMD PDUs with SN such that VR(R) <= SN < VR(MS) that has not been completely received yet, in 
increasing SN order, starting with SN = VR(R) up to the SN for which the resulting STATUS PDU fits to the 
total size of RLC PDU(s) indicated by lower layer: 

if no byte segments have been received yet for an AMD PDU: 

- include in the STATUS PDU a NACK_SN which is set to the SN of the AMD PDU; 

- else 

include in the STATUS PDU a set of NACK_SN, SOstart and SOend for each continuous sequence of 
byte segments of the AMD PDU that has not been received yet. 

set the ACK_SN to the SN of the next not received RLC Data PDU which is not indicated as missing in the 
resulting STATUS PDU. 

7.2.3.1 0.3 Test description 

7.2.3.10.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 
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UE: 

None. 

Preamble 



The UE is in state Loopback Activated (state 4) according to [18] with 1 RLC AM DRB configured (called 
DRBl) according to table 7.2.3.10.3.1-1. 

Table 7.2.3.10.3.1-1 : RLC settings 



Parameter 


Value 


T reordering 


200 ms 


T status prohibit 


300 ms 


T_poll_retransmit 


500 ms 



7.2.3.10.3.2 



Test procedure sequence 



Table 7.2.3.10.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: In parallel to the events 
described in steps 1 to 7, the UE performs the 
parallel behaviour specified in Table 

7.2.3.10.3.2-2 










1 


The SS transmits 4 AMD PDUs with SN=0, 1 , 
2, and 4 on DRB1 . The SS sets the P field of 
all the AMD PDUs too. 
Record time TA when the AMD PDU with 
SN=4 is sent. 


<— 


AMD PDU(SN=0, P=0) 
AMDPDU(SN=1, P=0) 
AMD PDU(SN=2, P=0) 
AMD PDU(SN=4, P=0) 






2 


Checkl : does the UE transmit a Status Report 
with NACK_SN=3 and ACK_SN=5? 
Record time Tb 
Check 2: (Tb - Ta) = T reordering 


— > 


STATUS PDU 


1 


P 


3 


Within (T_status_prohibit / 2) ms after the 
Status Report is received at Step 2, the SS 
transmits 4 AMD PDUs with SN=5, 6, 8 and 9 
on DRB 1 . The SS sets the P field of all the 
AMD PDUs too. 


<— 


AMD PDU(SN=5, P=0) 
AMD PDU(SN=6, P=0) 
AMD PDU(SN=8, P=0) 
AMD PDU(SN=9, P=0) 






4 


Checkl : does the UE transmit a Status Report 

with NACK SN=3, NACK SN=7 and 

ACK_SN=1 0? 

Record time Tc 

Check 2: (Tc - Tb) = T status prohibit 


— > 


STATUS PDU 


2 


P 


5 


The SS waits for T status prohibit. 


- 


- 


- 


- 


6 


The SS transmits 3 AMD PDUs with SN=3, 
SN=7, and SN=9 on DRB 1 . The SS sets the P 
field of all the AMD PDUs to except for that 
of the AMD PDU with SN=9. 


<— 


AMD PDU(SN=3, P=0) 
AMD PDU(SN=7, P=0) 
AMDPDU(SN=9, P=1) 






7 


Check; does the UE transmit a Status Report 
with no NACK SN and ACK SN = 10? 


— > 


STATUS PDU 


3 


P 



Table 7.2.3.10.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


UE transmits AMD PDUs to loop back the data 
received in the downlink 


— > 


AMD PDUs 


- 


- 
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7.2.3.10.3.3 Specific message contents 

None. 

7.2.3.1 2 AM RLC / Operation of the RLC re-establishment procedure / UE Terminated 

Editor's note: this test case description is not based on 36.322 v8.3.0. 

7.2.3.12.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is requested to perform a RRC Connection reconfiguration with RLC re-establishment } 
then { the UE discards the remaining AMD PDUs; and discards all RLC SDUs in the transmitting 
side; and reset all state variables to their initial values. } 
} 

Editor's note: The test purpose has been limited to verify that any remaining AMD PDUs in receiving side and any 
remaining RLC SDUs in transmitting side are discarded; and that state variables are reset to their initial 
values. Thus are the following conformance requirements not verified: 

(1) "discard all RLC control PDUs" - due to not feasible to trigger re-establishment of RLC entity while 
there is a RLC control PDU pending for transmission; 

(2) "when possible, reassemble RLC SDUs from any byte segments of AMD PDUs with SN < VR(MR) 
in the receiving side, remove RLC headers when doing so and deliver the reassembled RLC SDUs to 
upper layer" - due to not feasible to verify delivery to upper layer as the transmitting side will discard the 
returned UL SDU).; and 

(3) "stop and reset all timers" has not been included in this version of the test case and is FFS. Is it 
essential to verify in the RLC re-establishment test case?] 

7.2.3.12.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.322, clause 5.4. 
[TS 36.322, clause 5.4] 

RLC re-establishment is performed upon request by RRC, and the function is applicable for AM and UM RLC entities. 
When RRC indicates that an RLC entity should be re-established, the RLC entity shall: 
- if it is an AM RLC entity: 

- when possible, reassemble RLC SDUs from any byte segments of AMD PDUs with SN < VR(MR) in the 
receiving side, remove RLC headers when doing so and deliver the reassembled RLC SDUs to upper layer if 
not deUvered before; 

discard the remaining AMD PDUs and byte segments of AMD PDUs in the receiving side; 

- discard all RLC SDUs and AMD PDUs in the transmitting side; 

- discard all RLC control PDUs. 
stop and reset all timers; 

reset all state variables to their initial values. 
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Test description 
Pre-test conditions 



7.2.3.12.3 

7.2.3.12.3.1 

System Simulator: 
- Cell 1 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 

UL RLC SDU size is configured to be the same as received in DL RLC SDUs. 

Editor's note: It needs to be further studied if the test case should be expanded to use one additional AM DRB to 
verify that the UE is only performing the RLC re-establishment on the specific DRB as requested by the 
SS. 



7.2.3.12.3.2 



Test procedure sequence 



Table 7.2.3.12.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS creates 3 RLC SDUs of size [TBD] 
segmented into two AMD PDUs each. AMD 
PDU#1 and AMD PDU#2 belongs to RLC 
SDU#1 , AMD PDU#3 and #4 belongs to RLC 
SDU#2 and AMD PDU#5 and #6 belongs to 
RLC SDU#3. SS transmits AMD PDU#1 , AMD 
PDU#2 and AMD PDU#4. 


<— 


AMD PDU#1 
AMD PDU#2 
AMD PDU#4 






2 


Check: Does UE returns RLC SDU#1? 


— > 


(RLCSDU#1) 


1 


P 


3 


SS does not acknowledge the reception of 
RLCSDU#1. 


- 


- 


- 


- 


4 


SS performs a RRC Connection 
Reconfiguration procedure triggering an RLC- 
reestablishment of an RLC entity. 
See Note 1 . 










5 


SS transmits AMD PDU#5 with SN=0 and the 
P field set to "1" 


<— 


AMD PDU#5 




- 


6 


Check: Does the STATUS PDU report an AMD 
PDU with SN=3 as missing? (i.e. using 
NACK_SN, SOstart / SOend) 
See Note 2. 


— > 


STATUS PDU 




F 


7 


SS transmits AMD PDU#6 with 
SN=Receiving AM Window Size+2 


<— 


AMD PDU#6 




- 


8 


Check: Does UE return RLC SDU#3 within 

[1s]? 

See Note 3. 


— > 


(RLC SDU#3) 




F 


9 


SS transmits AMD PDU#6 with SN=2 


<— 


AMD PDU#6 




- 


10 


Check: Does UE return RLC SDU#3 with its 
first AMD PDU with SN=0? 


— > 


(RLC SDU#3) 




P 


Note 1 The conformant UE discards any remaining AMD PDUs in the receiver and transmitter side, stops and 

resets all timers and resets all state variables to their initial values. 
Note 2 AMD PDU#4 have been discarded by the conformant UE in step 4. 
Note 3 AMD PDU#6 have been discarded by the conformant UE due to being outside the receiving window size. 
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7.2.3.12.3.3 Specific message contents 

Table 7.2.3.12.3.3-1 : RRCConnectionReconfiguration (step 4) 



Derivation Path: 36.508 clause [TBD], Table Nr [TBD] | 


Information Element 


Value/remark 


Comment 


Condition 


RadioResourceConfiguration 








- RIc-ReestablishmentRequest 


true 







7.2.3.13 AM RLC / Reconfiguration of RLC parameters by upper layers 

Editor's note: this test case description is not based on 36.322 v8.3.0. 

7.2.3.13.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { the poll retransmit timer expires } 
then { UE transmits a Poll } 

} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { Reception failure of an RLC data PDU is detected } 
then { UE initiates Status Reporting } 
} 

Editor's note: this test purpose should be clarified as there are several ways to detect the reception failure. 
(3) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { Status Reporting is triggered and T_status_prohibit_timer is running} 
then { UE transmits a status report at T_status_prohibit_timer expiry } 
} 

(4) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { PDU_WITHOUT_POLL=Poll_PDU } 
then { UE transmits a Poll } 
} 

(5) 

with { UE in E-UTRA RRC_CONNECTED state and using AM RLC } 
ensure that { 

when { BYTE_WITHOUT_POLL=Poll_Byte } 
then { UE transmits a Poll } 
} 

7.2.3.13.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2.2 
and 5.2.3. 

[TS 36.322, clause 5.2.2] 

An AM RLC entity can poll its peer AM RLC entity in order to trigger STATUS reporting at the peer AM RLC entity. 

Triggers to initiate polling include: 

Transmission of last data in the buffer: 
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- The transmitting side of an AM RLC entity shall set the P field of an RLC data PDU to " 1 " if both the 
transmission buffer and the retransmission buffer becomes empty (excluding transmitted RLC data PDU 
awaiting for acknowledgements) after the transmission of the RLC data PDU; 

Expiry of poll retransmit timer: 

The transmitting side of an AM RLC entity shall: 

- upon delivering a RLC data PDU with the P field set to " 1 " to lower layer; 

if T_poll_retransmit is not running: 

start T_poll_retransmit; 

store the SN = VT(S) - 1 in memory; 
else: 

- restart T_poll_retransmit; 

- replace the stored SN in memory with the SN = VT(S) - 1 . 

stop T_poll_retransmit when it receives either a positive or negative acknowledgement for the 
corresponding RLC data PDU with the SN it stored in memory; 

when T_poll_retransmit expires: 

if both the transmission buffer and the retransmission buffer are empty (excluding transmitted RLC 
data PDU awaiting for acknowledgements): 

- consider the AMD PDU with SN = VT(S) - 1 for retransmission; 

set the P field of the RLC data PDU to be transmitted in the next transmission opportunity to " 1 "; 
else: 

set the P field of the RLC data PDU to be transmitted in the next transmission opportunity to " 1 ". 
- Every Poll_PDU PDUs: 

The transmitting side of an AM RLC entity shall: 

maintain a counter PDU_WITHOUT_POLL, which is initially set to 0; 

- increment PDU_WITHOUT_POLL by one for every new AMD PDU that it forms; 

- set the P field of an AMD PDU that it forms to " 1 " when PDU_WITHOUT_POLL = Poll_PDU; 

- reset PDU_WITHOUT_POLL to when it delivers to lower layer a RLC data PDU whose P field is set 

to "1". 

Every Poll_Byte bytes: 

The transmitting side of an AM RLC entity shall: 

maintain a counter BYTE_WITHOUT_POLL, which is initially set to 0; 

increment B YTE_WITHOUT_POLL for every new byte of Data field element that it maps to the Data 
field of an AMD PDU; 

- set the P field of an AMD PDU that it forms to " 1 " when B YTE_WITHOUT_POLL >= Poll_Byte; 

- reset BYTE_WITHOUT_POLL to when it delivers to lower layer a RLC data PDU whose P field is set 

to "1". 

Editor's note: Whether or not the polling trigger "Every Poll_PDU PDUs" and "Every Poll_Byte bytes" are 
configurable or not is FES. It has been decided that other polling triggers are always enabled.] 
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[TS 36.322, clause 5.2.3] 

An AM RLC entity sends STATUS PDUs to its peer AM RLC entity in order to provide positive and/or negative 
acknowledgements of RLC PDUs (or portions of them). 

RRC configures whether or not the status prohibit function is to be used for an AM RLC entity. 

Triggers to initiate STATUS reporting include: 

Polling from its peer AM RLC entity: 

The receiving side of an AM RLC entity shall trigger a STATUS report when it receives a RLC data PDU 
with the P field set to "1" and the HARQ reordering of the corresponding RLC data PDU is completed. 

Detection of reception failure of an RLC data PDU: 

The receiving side of an AM RLC entity shall trigger a STATUS report when T_reordering expires. 

NOTE: The expiry of T_reordering triggers both VR(MS) to be updated and a STATUS report to be triggered, 
but the STATUS report shall be triggered after VR(MS) is updated. 

When STATUS reporting has been triggered, the receiving side of an AM RLC entity shall: 

if T_status_prohibit is not running: 

at the first transmission opportunity indicated by lower layer, construct a STATUS PDU and deliver it to 
lower layer; 

else: 

at the first transmission opportunity indicated by lower layer after T_status_prohibit expires, construct a 
single STATUS PDU even if status reporting was triggered several times while T_status_prohibit was 
running and deliver it to lower layer; 

When a STATUS PDU has been delivered to lower layer, the receiving side of an AM RLC entity shall: 

start T_status_prohibit. 

When constructing a STATUS PDU, the AM RLC entity shall: 

- for the AMD PDUs with SN such that VR(R) <= SN < VR(MS) that has not been completely received yet, in 
increasing SN order, starting with SN = VR(R) up to the SN for which the resulting STATUS PDU fits to the 
total size of RLC PDU(s) indicated by lower layer: 

if no byte segments have been received yet for an AMD PDU: 

- include in the STATUS PDU a NACK_SN which is set to the SN of the AMD PDU; 

- else 

include in the STATUS PDU a set of NACK_SN, SOstart and SOend for each consecutive byte segments 
of the AMD PDU that has not been received yet. 

set the ACK_SN to the SN of the next not completely received AMD PDU which is not indicated with a 
NACK_SN in the resulting STATUS PDU. 

7.2.3.1 3.3 Test description 

7.2.3.13.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 
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UE: 

None. 



Preamble: 



The UE is in state Loopback Activated (state 4) according to [18], with the exceptions as specified in table 
7.2.3.13.3.1-1 and 7.2.3.13.3.1-2 and with the UL SDU size set to [FFS] bytes. 

Table 7.2.3.13.3.1-1 : MAC Settings 

Parameter Value 

DL TBSize FFS octets 

UL TBSize DL TBSize 



Table 7.2.3.13.3.1-2: RLC settings 



Parameter 


Value 


T_reordering 


50 ms 


T_status_prohibit 


150 ms 


T poll retransmit 


FFS 


Poll PDU 


10 


PolLByte 


2 X (TBSize - 3) 
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7.2.3.13.3.2 



Test procedure sequence 



Table 7.2.3.13.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 




The SS re-establishes RLC in the UE and sets 

- T_reordering to [tbd], 

- T_status_prohibit to [tbd], 

- T poll retransmit to [tbd], 
-Poll PDU to [tbd], 

- Poll Byte to [tbd]. 










1 


The SS transmits 4 AMD PDUs with P=0 and 
SN=0, 1,2 and 4. 

The SS record time Ta when AMD PDU 5 (with 
SN=4) is sent. 


<— 


AMD PDU (SN=0, P=0) 
AMDPDU(SN=1, P=0) 
AMD PDU (SN=2, P=0) 
AMD PDU (SN=4, P=0) 






3 


Checkl : Does the UE transmit a SR on 
PUCCH? Record time Tg. 
Check2: (Tb - Ta) = T reordering 


— > 


(SR) 


2 


P 


4 


The SS transmits an UL grant to the UE. 


<— 


(UL grant) 


- 


- 


5 


Checkl : does the UE transmit a Status Report 
with NACK_SN=3 and ACK_SN=5? Record 
time Tb. 
Check2: (Tb - Ta) = T reordering 


— > 


STATUS PDU 


2,3 


P 


6 


The SS sends 4 AMD PDU with SN=5, 6, 8 and 
9 within (T_status _prohibit / 2 ) ms after it 
receives the SR in step 2 above. 


<— 


AMD PDU (SN=5, P=0) 
AMD PDU (SN=6, P=0) 
AMD PDU (SN=8, P=0) 
AMD PDU (SN=9, P=0) 






7 


Check 1 : does the UE transmit SR on PUCCH? 

Report. Record time Tc. 

Check 2: (Tc -Tb)=T status prohibit 


— > 


(SR) 


2 


P 


8 


The SS transmits an UL grant to the UE. 


<- 


(UL grant) 


- 


- 


9 


Checkl : does the UE transmit a Status Report 
with NACK SN=3, NACK SN=7 and 
ACK_SN=10? Record time Tc. 
Check2: (Tc -Tb) = T status prohibit 


— > 


STATUS PDU 


2,3 


P 


10 


The SS waits for T status prohibit/2. 


- 


- 


- 


- 


11 


The SS transmits 3 AMD PDUs with SN=3, 7, 9 


<— 


AMD PDU (SN=3, P=0) 
AMD PDU (SN=7, P=0) 
AMDPDU(SN=9, P=1) 






12 


The SS transmits an UL grant to the UE. 


<— 


(UL grant) 


- 


- 


13 


Check: does the UE transmit a Status Report 
with no NACK SN and ACK SN = 10? 


— > 


STATUS PDU 


- 


- 


14 


Close Test Loop 


- 


- 


- 


- 


15 


The SS transmits 4 AMD PDUs with (TBSize - 
3) data octets 


<— 


AMD PDU (SN=0, P=0) 
AMDPDU(SN=1, P=0) 
AMD PDU (SN=2, P=0) 
AMD PDU (SN=3, P=0) 






16 


The SS transmits four UL grants with size 
TBSize octets in each of them. 


<— 


(UL grant) 


- 


- 




EXCEPTION: Step 1 7 shall be repeated for 4 
times. Where n=0, 1 , 2 and 3. Polling bit is only 
enabled for n=3 










17 


Check: does the UE transmit 4 AMD PDUs with 
SN and P bit as indicated? 


— > 


AMD PDU (SN=0, P=0) 
AMDPDU(SN=1, P=0) 
AMD PDU (SN=2, P=0) 
AMDPDU(SN=3, P=1) 


? 


? 


18 


Record time Ta when the last PDU is received 
from the UE. 










19 


The SS does not send any RLC Status Report. 


- 


- 


- 


- 


20 


Check 1 : does the UE transmit SR on PUCCH? 

Record time TB. 

Check 2: (TB - TA ) = T status retransmit 


— > 


(SR) 






21 


The SS sends an UL grant size TBSize to the 
UE. 


<— 


(UL grant) 


- 


- 


22 


Check: does the UE transmit an AMD PDU with 
SN=3and P=1. 


— > 


AMDPDU(SN=3, P=1) 


1 


P 
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23 


The SS transmits an RLC Status Report. 


<- 


STATUS PDU 


- 


- 


24 


Check: does the UE transmit a SR on PUCCH 
within T poll retransmit ms? 


- 


(SR) 


? 


F 


25 


The SS transmits (2''Poll PDU) AMD PDUs 
with SN=( 4, ..., 4+2*Poll_PDU-1) with 
(TBSize-3) data octets 


<— 


AMD PDU (SN=4) 
AMD PDU (SN=5) 

AMD PDU (SN= 4+2*Poll PDU-1) 






26 


The SS transmits Poll_PDU UL grants with size 
TBSize octets in each of them. 


<— 


(UL grants) 


- 


- 


27 


Check: Does the UE transmit (Poll_PDU) AIVID 
PDUs with SN as indicated? 


— > 


AMD PDU (SN=4) 
AMD PDU (SN=5) 

AMDPDU(SN=4+Poll PDU-1) 


? 


? 


28 


The SS transmits a Status Report with 
NACK SN=14andNACK SN=15. 


<— 


STATUS PDU 


- 


- 


29 


The SS transmits two UL grants with size 
TBSize octets in each of them. 


<— 


(UL grants) 


- 


- 


30 


Check: does he UE transmit an AMD PDU with 
SN=4, P=0? 


— > 


AMD PDU (SN=4, P=0) 


- 


- 


31 


Check: does the UE transmit an AMD PDU with 
SN=5, P=0? 


— > 


AMD PDU (SN=5, P=0) 


- 


- 


32 


The SS transmits Poll_PDU UL grants with size 
TBSize octets in each of them. 


<— 


(UL grants) 


- 


- 


33 


Check: Does the UE transmit (Poll_PDU) AMD 
PDUs with SN and P bit as indicated? 


— > 


AMD PDU (SN=4+Poll PDU, 

P=0) 

AMD PDU (SN=5+Poll PDU, 

P=0) 

AMD PDU (SN= 4+2*Poll PDU-1 , 

P=1) 


4 


P 


34 


Check: Does the UE transmit (Poll_PDU) AMD 
PDUs with SN as indicated? 


— > 


AMD PDU (SN=4+2*Poll PDU,) 
AMD PDU (SN=5+2*Poll PDU) 
AMD PDU (SN=6+2*Poll PDU) 
AMD PDU (SN=7+2*Poll PDU) 






35 


The SS transmits and AMD PDU with (TBSize 
- 3) data octets. 


<— 


AMD PDU 


- 


- 


36 


The SS transmits four UL grants with size 
TBSize octets in each of them. 


<— 


(UL grants) 


- 


- 




EXCEPTION: Step 37 shall be repeated for 
Poll PDU times. n=4 + 2 X Poll PDU, 5 + 2 x 
PolLPDU, 6 + 2 X PolLPDU, 7 + 2 X Poll_PDU. 
Polling bit is only enabled for n=5 + 2 x 
Poll PDU and n=7 + 2 x Poll PDU. 










37 


Check: Does the UE transmit (Poll_PDU) AMD 
PDUs with SN and P bit as indicated? 


— > 


AMD PDU (SN=4+2*Poll PDU, 

P=0) 

AMD PDU (SN=5+2*Poll PDU, 

P=1) 

AMD PDU (SN=6+2*Poll PDU, 

P=0) 

AMD PDU (SN=7+2*Poll PDU, 

P=1) 


5 


P 


38 


The SS transmits a STATUS PDU to the UE. 
This PDU acknowledges PDUs up to 7 + 2 x 
Poll PDU. 


<— 


STATUS PDU 







7.2.3.13.3.3 
None. 



Specific message contents 
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7.2.3.14 AM RLC / In sequence delivery of upper layers PDUs 

7.2.3.14.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives duplicate AMD PDUs } 

then { UE discards the duplicate AMD PDUs } 
} 

(2) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives an AMD PDU with a SN gap } 

then { UE sends STATUS PDU to request retransmissions of PDUs in the SN gap} 
} 

(3) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives PDUs within a SN gap } 
then { RLC reassembles and reorders the AMD PDUs and deliver them to the upper layer in sequence } 



7.2.3.14.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 
4.2.1.3.3. 

[TS 36.322, clause 4.2.1.3.3] 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 

detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data 
PDUs; 

reorder the RLC data PDUs if they are received out of sequence; 

detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity; 

reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in 
sequence. 



7.2.3.14.3 




7.2.3.14.3.1 




System Simu 


ilator: 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 



Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.2.3.14.3.2 



Test procedure sequence 



Table 7.2.3.14.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an AMD PDU to the UE. This 
PDU carries SDU#1. 


<— 


AMD PDU#1 






2 


The SS transmits an AIVID PDU to the UE. This 
PDU carries SDU#1. 


<— 


AMD PDU#1 


- 


- 


3 


Checl<: does the UE transmit RLC SDU#1 ? 


-> 


(RLCSDU#1) 


1 


P 


4 


The SS transmits an AIVID PDU to the UE. This 
PDU contains SDU#2, and the l" part of 
SDU#3. 


<— 


AMD PDU#2 






5 


Checl<: does the UE transmit RLC SDU#2? 


-> 


(RLC SDU#2) 


1 


P 


6 


The SS transmits an AIVID PDU to the UE. This 
PDU contains SDU#2, and the 1" part of 
SDU#3. 


<-- 


AMD PDU#2 






7 


Check: does the UE transmit RLC SDU#2? 


-> 


(RLC SDU#2) 


1 


F 


8 


The SS transmits an AIVID PDU to the UE. This 
PDU contains the 2"'^ part of SDU#3. 


<— 


AMD PDU#3 


- 


- 


9 


Check: does the UE transmit RLC SDU#3? 


-> 


(RLC SDU#3) 


1 


P 


10 


The SS transmits an AMD PDU to the UE. This 
PDU contains the last part of SDU#6. 


<— 


AMD PDU#6 


- 


- 


11 


The SS transmits an AMD PDU to the UE. This 
PDU contains SDU#5, and the 1" part of 
SDU#6. 


<— 


AMD PDU#5 






12 


The SS transmits an AMD PDU to the UE. This 
PDU carries SDU#4 and the 1" part of SDU#5. 


<— 


AMD PDU#4 


- 


- 


13 


Check: does the UE transmit RLC SDU#4? 


-> 


(RLC SDU#4) 


3 


P 


14 


Check: does the UE transmit RLC SDU#5? 


-> 


(RLC SDU#5) 


3 


P 


15 


Check: does the UE transmit RLC SDU#6? 


-> 


(RLC SDU#6) 


3 


P 


16 


The SS transmits an AMD RLC PDU [FFS] 
bytes to the UE. This PDU contains the last 
part of SDU#9. 


<-- 


AMD PDU#9 






17 


Check: does the UE transmit a STATUS PDU 
NACK SN/E1/E2 fields set correctly to inform 
SS of missing PDUs #7, #8, (ACK SN =10, 
NACK SN = 7, NACK SN = 8).? 


--> 


STATUS PDU 


2 


P 


18 


The SS transmits an AMD PDU to the UE. This 
PDU contains SDU#8, and the 1" part of 
SDU#9. 


<— 


AMD PDU#8 






19 


The SS transmits an AMD PDU to the UE. This 
PDU carries SDU#7. 


<— 


AMD PDU#7 


- 


- 


20 


Check: does the UE transmit RLC SDU#7? 


-> 


AMD PDU#7 


3 


P 


21 


Check: does the UE transmit RLC SDU#8? 


-> 


AMD PDU#8 


3 


P 


22 


Check: does the UE transmit RLC SDU#9? 


-> 


AMD PDU#9 


3 


P 



7.2.3.14.3.3 
None. 



Specific message contents 



7.2.3.1 5 AM RLC / Re-ordering of RLC PDU segments 

7.2.3.15.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives RLC AM PDU segments } 

then { UE reorders RLC AMD PDU segments received out of sequence 
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(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { Treordering expires } 

then { Set VR{MS) to SN >= T_reordering state variable. For first AMD PDU where not all SDU 
Segments have been received } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state when T_reordering expires } 
ensure that { 

when { VR{H) > VR{MS) } 

then { start T_reordering timer and set VR{X) to VR{H)} 
} 

7.2.3.15.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 
4.2.1.3.3, 5.1.3.2.1, 5.1.3.2.2, 5.1.2.3.3 and5. 1.2.3.4. 

[TS 36.322, clause 4.2.1.3.3] 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 



detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity; 

reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in 
sequence. 



[TS 36.322, clause 5.1.3.2.1] 

The receiving side of an AM RLC entity shall maintain a receiving window according to state variables VR(R) and 
VR(MR) as follows: 

- a SN falls within the receiving window if VR(R) <= SN < VR(MR); 

a SN falls outside of the receiving window otherwise. 

When receiving a RLC data PDU from lower layer, the receiving side of an AM RLC entity shall: 

either discard the received RLC data PDU or place it in the reception buffer (see sub clause 5.1.3.2.2); 

if the received RLC data PDU was placed in the reception buffer: 

update state variables, reassemble and deliver RLC SDUs to upper layer and start/stop T_reordering as 
needed (see sub clause 5.1.3.2.3). 

When T_reordering expires, the receiving side of an AM RLC entity shall: 

update state variables and start T_reordering as needed (see sub clause 5.1.3.2.4). 

[TS 36.322, clause 5.1.3.2.2] 

When a RLC data PDU is received from lower layer, where the RLC data PDU contains byte segment numbers y to z of 
an AMD PDU with SN = x, the receiving side of an AM RLC entity shall: 

if X falls outside of the receiving window; or 

if byte segment numbers y to z of the AMD PDU with SN = x have been received before: 

discard the received RLC data PDU; 
otherwise: 

place the received RLC data PDU in the reception buffer; 
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if some byte segments of the AMD PDU contained in the RLC data PDU have been received before: 

- discard the duplicate byte segments. 
[TS 36.322, clause 5.1.3.2.3] 

When a RLC data PDU with SN = x is placed in the reception buffer, the receiving side of an AM RLC entity shall: 

- if all byte segments of the AMD PDU with SN = VR(MS) are received: 

- update VR(MS) to the SN of the first AMD PDU with SN > current VR(MS) for which not all byte segments 
have been received; 

- ifx = VR(R): 

- if all byte segments of the AMD PDU with SN = VR(R) are received: 

- update VR(R) to the SN of the first AMD PDU with SN > current VR(R) for which not all byte segments 
have been received; 

- update VR(MR) to the updated VR(R) + AM_Window_Size; 

reassemble RLC SDUs from any byte segments of AMD PDUs with SN that falls outside of the receiving 
window and in-sequence byte segments of the AMD PDU with SN = VR(R), remove RLC headers when 
doing so and deliver the reassembled RLC SDUs to upper layer in sequence if not delivered before; 

- ifx>=VR(H) 

- update VR(H) to x+ 1; 
if T_reordering is running: 

- ifVR(X) = VR(R);or 

if VR(X) falls outside of the receiving window: 
stop and reset T_reordering; 

- set VR(X) to NULL; 

if T_reordering is not running (includes the case T_reordering is stopped due to actions above): 

- iftheVR(H)>VR(R): 

start T_reordering; 

- set VR(X) to VR(H). 
[TS 36.322, clause 5.1.3.2.4] 

When T_reordering expires, the receiving side of an AM RLC entity shall: 

- update VR(MS) to the SN of the first AMD PDU with SN >= VR(X) for which not all byte segments have been 
received; 

- ifVR(H)>VR(MS): 

start T_reordering; 

- set VR(X) to VR(H); 
otherwise: 

- set VR(X) to NULL. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 175 ETSI TS 136 523-1 V8.0.1 (2009-01) 

Test description 
Pre-test conditions 



7.2.3.15.3 




7.2.3.15.3.1 




System Simu 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18] with a loop back size of 102 bytes. 
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7.2.3.15.3.2 



Test procedure sequence 



Table 7.2.3.15.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 


1 


The SS transmits 1 RLC PDU of 1 00 data 
bytes to the UE. SN=7 indicates the loss of 7 
PDUs. The P-bit is set. 


<— 


AIVID PDU#8 






2 


The SS transmits one AIVID PDU of 50 data 
bytes to the UE. This PDU carries part 1of 
PDU#1.SO=0andLSF=0. 


<— 


AMD PDU#1 
segment 1 






3 


The SS transmits one AIVID PDU of 50 data 
bytes to the UE. This PDU carries part 2 of 
PDU#2. SO=50andLSF=1. 


<— 


AMD PDU#2 
segment 2 






4 


The SS transmits one AMD PDU of 50 data 
bytes to the UE. This PDU carries part 1of 
PDU#3. SO=0 and LSF=0. 


<— 


AMD PDU#3 
segment 1 






5 


The SS transmits one AIVID PDU of 50 data 
bytes to the UE. This PDU carries part 2 of 
PDU#4. SO=50andLSF=1. 


<— 


AMD PDU#4 
segment 2 






6 


The SS transmits one AIVID PDU of 50 data 
bytes to the UE. This PDU carries part 1of 
PDU#4. SO=0 and LSF=0. 


<— 


AMD PDU#4 
segment 1 






7 


The SS transmits one AIVID PDU of 50 data 
bytes to the UE. This PDU carries part 2 of 
PDU#1.SO=50andLSF=1. 


<— 


AMD PDU#1 
segment 2 






8 


Check: does the UE transmit an RLC SDU with 
same content as received in the corresponding 
DL PDU segments? 


— > 


(RLCSDU#1) 


1 


P 


9 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries part 1 of 
PDU#2. SO=0 and LSF=0. 


<— 


AMD PDU#2 
segment 1 






10 


Check: does the UE transmit an RLC SDU with 
the same PDU content as received in the 
corresponding DL PDU segments? 


— > 


(RLC SDU#2) 


1 


P 


11 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries part 1of 
PDU#3. SO=50andLSF=1. 


<— 


AMD PDU#3 
segment 2 






12 


Check: does the UE transmit an AIVID PDU 
with same content as received in the 
corresponding DL PDU segments? 


— > 


(RLC SDU#3) 


1 


P 


13 


Check: does the UE transmit an AIVID PDU 
with same content as received in the 
corresponding DL PDU segments? 


— > 


(RLC SDU#4) 


1 


P 


14 


The SS transmits an RLC STATUS PDU to the 
UE. This PDU acks PDUs up to those 
including SDU#4. 


<— 


STATUS PDU 






15 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries segment 1of 
PDU 7. SO=0 and LSF=0. 


<— 


AMD PDU#7 
segment 1 






16 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries segment 2 
ofPDUe. SO=50andLSF=1. 


<— 


AMD PDU#6 
segment 2 






17 


Wait T reordering to run out at the UE side 


- 








18 


Check: does the UE transmit a Status Report 
with NACK SN=5 with SOStart=0 and 
SOEnd=49, and NACK_SN=6 with 
SOStart=50 and SOEnd=special value, and 
ACK SN=5? 


— > 


STATUS PDU 




P 


19 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries part 1of 
PDU#7. SO=50andLSF=1. 


<— 


AMD PDU#7 
segment 2 






20 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries part 1of 
PDU#6. SO=0 and LSF=0. 


<— 


AMD PDU#6 
segment 1 






21 


The SS transmits one RLC PDU of 50 data 


<— 


AMD PDU#5 
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bytes to the UE. This PDU carries part lot 
PDU#5. SO=0 and LSF=0. 




segment 1 






22 


Wait T reordering to run out at the UE side 


- 








23 


Checl<: Does the UE transmit a Status Report 
with NACK SN=5 with SOStart=0 and 
SOEnd=49, and ACK SN=8? 


— > 


STATUS PDU 




P 


24 


The SS transmits one RLC PDU of 50 data 
bytes to the UE. This PDU carries part lot 
PDU5. SO=50andLSF=1. 


<— 


AMD PDU#5 
segment 2 






25 


Checl<: does the UE transmit an AIVID PDU 
with same content as received in the 
corresponding DL PDU segments? 


--> 


(RLC SDU#5) 


2,3 


P 


26 


Checl<: does the UE transmit an AIVID PDU 
with same content as received in the 
corresponding DL PDU segments? 


--> 


(RLC SDU#6) 


2,3 


P 


27 


Checl<: does the UE transmit an AIVID PDU 
with same content as received in the 
corresponding DL PDU segments? 


— > 


(RLC SDU#7) 


2,3 


P 


29 


The SS transmits an RLC STATUS PDU to the 
UE. This PDU acks PDUs up to those 
including SDU#7.. 


<— 


STATUS PDU 







Editor's note: In the table above, the RLC SDUs which are checked in uplink are called "PDUs" in the 'Procedure" 
column when transmitted in downlink. For consistency, they could be called "RLC SDUs" in both 
directions. 

Editor's note: In the table above, when checking uplink data, the "message" column indicates which data are 

expected (i.e. which RLC SDU) while the "procedure" column uses a wording which does not indicate 
any RLC SDU. If the intention is to check the data contents of the PDU in the "message" column, this 
should be clarified in the "procedure" column. 

Editor's note: In steps 14 and 28, the contents of SATUS PDU is not provided. 



7.2.3.15.3.3 
None. 



Specific message contents 



7.2.3.16 AM RLC / Re-transmission of RLC PDU without re-segmentation 

Editor's note: this test case description is not based on 36.322 v8.3.0. 

7.2.3.16.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives a STATUS PDU including a NACK_SN for missing AMD PDUs and missing AMD PDUs can 
fit into within the total size of RLC PDU{s) indicated by lower layer at the particular transmission 
opportunity} 
then { UE successfully retransmits missing AMD PDUs without re-segmentation} 

} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { NACK received for missing AMD PDUs and RETX_COUNT = Max_Retx_Threshold } 
then { UE indicates to upper layers that max retransmission has been reached } 
} 

Editor's note: TP2 may be affected by RAN2 #63'bis' discussions 

7.2.3.16.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clause 5.2. L 
[TS 36.322 ver 8.2.0 clause 5.2.1] 
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The transmitting side of an AM RLC entity can receive a negative acknowledgement (notification of reception failure 
by its peer AM RLC entity) for an AMD PDU or a portion of an AMD PDU by the following: 

- STATUS PDU from its peer AM RLC entity; 

HARQ delivery failure from the transmitting MAC entity. 

When receiving a negative acknowledgement for an AMD PDU or a portion of an AMD PDU by a STATUS PDU from 
its peer AM RLC entity, the transmitting side of the AM RLC entity shall: 

- if the SN of the corresponding AMD PDU falls within the range VT(A) <= SN < VT(S): 

consider the AMD PDU or the portion of the AMD PDU for which a negative acknowledgement was 
received for retransmission. 

When receiving a negative acknowledgement for an AMD PDU or a portion of an AMD PDU by HARQ delivery 
failure notification from the transmitting MAC entity, the transmitting side of the AM RLC entity may: 

- if the SN of the corresponding AMD PDU falls within the range VT(A) <= SN < VT(S): 

consider the AMD PDU or the portion of the AMD PDU for which a negative acknowledgement was 
received for retransmission. 

When an AMD PDU or a portion of an AMD PDU is considered for retransmission, the transmitting side of the AM 
RLC entity shall: 

if it is considered for retransmission for the first time: 

- set the RETX_COUNT associated with the AMD PDU to zero; 

else, if it or a portion of it has been delivered to lower layers for transmission since the last increment of 
RETX_COUNT or RETX_COUNT = 0: 

- increment the RETX_COUNT; 

- if RETX_COUNT = Max_Retx_Threshold: 

indicate to upper layers that max retransmission has been reached. 

When retransmitting an AMD PDU, the transmitting side of an AM RLC entity shall: 

if the AMD PDU can entirely fit within the total size of RLC PDU(s) indicated by lower layer at the particular 
transmission opportunity, deliver the AMD PDU as it is except for the P field (the P field should be set according 
to sub clause 5.2.2); 



7.2.3.16.3 Test description 

7.2.3.16.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

UE: 
None. 



Preamble: 



The UE is in state Loopback Activated (state 4) according to [18], with the exceptions as specified in table 
7.2.3.16.3.1-1. 

UL SDU size is set to return same size as received in downlink. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



179 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



Table 7.2.3.16.3.1-1 : MAC Settings 



Parameter 


Value 


DL TBSize 


FFS octets 


UL TBSize 


DL TBSize 


Max Retx Threshold 





7.2.3.16.3.2 



Test procedure sequence 



Table 7.2.3.16.3.2-1 : Main behaviour 



St 


Procedure 


U-S 


Message Sequence 
Message 


TP 


Verdict 


1 


The SS transmits 20 RLC SDUs each with an 
AMD PDU with SN=0 to 19, Fl field set to "00" 
and P field set to "0". 


<- 


AMD PDU(SN=0) 
AMDPDU(SN=1) 

AMDPDU(SN=19) 


? 


? 


2 


The SS transmits a grant with TBS=RB Size + 
RLC header size + MAC header size 


<— 


(UL grant) 






3 


Check: does the UE transmit 20 RLC SDUs 
each in an AMD PDU as indicated? 


-> 


AMD PDU(SN=0, Fl=00, P=0) 
AMDPDU{SN=1, Fl=00, P=G) 

AMD PDU (SN=19, Fl=00, P=1) 


9 


9 


4 


The SS transmits a RLC STATUS PDU. 
SN ACK field set to "18", El field set to "1", 
SN NACK field set to "4", E2 field set to "0", 
El field set to "1 ", SN NACK field set to "7", 
E2 field set to "0", E1 field set to "1", 
SN NACK field set to "8", E2 field set to "0" 


<- 


STATUS PDU 






5 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "4", Fl field set to "00" and 
P field set to "0? 


-> 


AMD PDU (SN=4) 


1 


P 


6 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "7", Fl field set to "00" and 
P field set to "0"? 


-> 


AMD PDU (SN=7) 


1 


P 


7 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "8", Fl field set to "00" and 
P field set to "0"? 


-> 


AMD PDU (SN=8) 


1 


P 


8 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "18", Fl field set to "00" 
and P field set to "0"? 


-> 


AMDPDU(SN=18) 


1 


P 


9 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "19", Fl field set to "00" 
and P field set to "0"? 


-> 


AMDPDU(SN=19, P=1) 


1 


P 


- 


EXCEPTION: Step 10 to 12 shall be repeated 
Max Retx Threshold times 


- 


- 


- 


- 


10 


The SS transmits a STATUS PDU. SN ACK 
field set to "20", E1 field set to "1 ", SN NACK 
field set to "4", E2 field set to "0", El field set 
to "1 ", SN NACK field set to "7", E2 field set to 
"0" 


<- 


STATUS PDU 






11 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "4", Fl field set to "00" and 
P field set to "0"? 


~> 


AMD PDU (SN=4) 


1 


P 


12 


Check: does the UE transmit RLC PDUs in an 
AMD PDU with SN "7", Fl field set to "00" and 
P field set to "0"? 


-> 


AMD PDU (SN=7) 


1 


P 


13 


The SS transmits an UL grant. 


<— 


(UL grant) 


2 


P 


14 


Check: does UE transmit an AMD PDU with 
SN=4 or SN=7? 




- 


2 


F 



Editor's note: It should be clarified what is exactly checked with respect to "RLC PDUs in an AMD PDU" 



7.2.3.16.3.3 
None. 



Specific message contents 
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7.2.3.17 AM RLC / Re-segmentation RLC PDU / SO, Fl, LSF 

7.2.3.17.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { AMD PDU to be retransmitted does not fit in new allocated TBS } 
then { UE segments AMD PDU into AMD PDU segments } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { AMD PDU segment to be retransmitted does not fit in new allocated TBS } 
then { UE resegments AMD PDU segment to fit TBS } 
} 

7.2.3.17.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 
4.2.1.3.2, 5.2.1, 6.2.1.4 and 6.2.1.5. 

[TS 36.322, clause 4.2.1.3.2] 

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs, it shall: 

- segment and/or concatenate the RLC SDUs so that the AMD PDUs fit within the total size of RLC PDU(s) 
indicated by lower layer at the particular transmission opportunity notified by lower layer. 

The transmitting side of an AM RLC entity supports retransmission of RLC data PDUs (ARQ): 

if the RLC data PDU to be retransmitted does not fit within the total size of RLC PDU(s) indicated by lower 
layer at the particular transmission opportunity notified by lower layer, the AM RLC entity can re-segment the 
RLC data PDU into AMD PDU segments; 

the number of re-segmentation is not limited. 

When the transmitting side of an AM RLC entity forms AMD PDUs from RLC SDUs received from upper layer or 
AMD PDU segments from RLC data PDUs to be retransmitted, it shall: 

include relevant RLC headers in the RLC data PDU. 

[TS 36.322 clause 5.2.1] 



When retransmitting an AMD PDU, the transmitting side of an AM RLC entity shall: 

if the AMD PDU can entirely fit within the total size of RLC PDU(s) indicated by lower layer at the particular 
transmission opportunity: 

deliver the AMD PDU as it is except for the P field (the P field should be set according to sub clause 5.2.2); 

otherwise: 

segment the AMD PDU and form a new AMD PDU segment which will fit within the total size of RLC 
PDU(s) indicated by lower layer at the particular transmission opportunity. 

When retransmitting a portion of an AMD PDU, the transmitting side of an AM RLC entity shall: 

segment the portion of the AMD PDU as necessary and form a new AMD PDU segment which will fit within 
the total size of RLC PDU(s) indicated by lower layer at the particular transmission opportunity. 

When forming a new AMD PDU segment, the transmitting side of an AM RLC entity shall: 

- only map the Data field of the original AMD PDU to the Data field of the new AMD PDU segment; 
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set the header of the new AMD PDU segment in accordance with the description in sub clause 6.; 

set the P field according to sub clause 5.2.2. 

[TS 36.322, clause 6.2.1.4] 

AMD PDU consists of a Data field and an AMD PDU header. 

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields 
that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and 
consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and 
consists of E(s) and LI(s). 

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the 
AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an 
AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI 

[TS 36.322, clause 6.2.1.5] 

AMD PDU segment consists of a Data field and an AMD PDU segment header. 

AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an 
extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU 
segment header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension 
part of the AMD PDU segment header itself is byte aligned and consists of E(s) and LI(s). 

An AMD PDU segment header consists of an extension part only when more than one Data field elements are present 
in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. 
Furthermore, when an AMD PDU segment header consists of an odd number of LI(s), four padding bits follow after the 
last LI. 



Test description 
Pre-test conditions 



7.2.3.17.3 




7.2.3.17.3.1 




System Simu 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18] with a loop back size of 102 bytes. 
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7.2.3.17.3.2 



Test procedure sequence 



Table 7.2.3.17.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 


1 


The SS transmits one AMD PDU of 1 00 data 
bytes. This PDU carries SDU#1 . 


<— 


AMD PDU#1 






2 


Checl<: does the UE transmit an AIVID PDU 
with the same content as received in the 
corresponding part of DL PDU 1 ? 


— > 


AMD PDU(SN=0) 






3 


The SS transmits a STATUS PDU. This PDU 
nacl<s the first byte in the AIVID PDU with 
SN=0. NACK SN=0 with SOStart=0 and 
SOEnd=0, and ACK SN=0. 


<— 


STATUS PDU 






4 


Check: does the UE transmit an AIVID PDU 
segment with SO=0, LSF=0 and the same 
content at the requested position as in the 
original AMD PDU? 


— > 


AMD PDU#1 segment 1(SN=0) 


1 


P 


5 


The SS transmits a STATUS PDU. 
SN ACK=1. 


<— 


STATUS PDU 


- 


- 


6 


The SS transmits one AMD PDU of 1 00 data 
bytes. This PDU carries SDU#2. 


<— 


AMD PDU#2 


- 


- 


7 


The UE transmits an AMD PDU which carries 
SDU#2. 


— > 


AMDPDU(SN=1) 


- 


- 


8 


The SS transmits a STATUS PDU. This PDU 
nacks the first 10 bytes in the AMD PDU with 
SN=1. NACK SN=1 with SOStart=0 and 
S0End=9, and ACK SN=1. 


<— 


STATUS PDU 






9 


Check: does the UE transmit an AMD PDU 
segment with SO=0, LSF=0 and the same 
content at the requested positions as in the 
original AMD PDU? 


— > 


AMD PDU#2 segment 1(SN=1) 


1 


P 


10 


The SS transmits a STATUS PDU. This PDU 
nacks the first byte in the AMD PDU with 
SN=1. NACK SN=1 with S0Start=2 and 
S0End=6, and ACK SN=1. 


<— 


STATUS PDU 






11 


Check: does the UE transmit an AMD PDU 
segment with S0=2, LSF=0 and the same 
content at the requested positions as in the 
original AMD PDU? 


— > 


AMD PDU#2 segment 2 (SN=1 ) 


2 


P 


12 


The SS transmits a STATUS PDU. 
SN ACK=2. 


<— 


STATUS PDU 


- 


- 


13 


The SS transmits one AMD PDU of 100 bytes. 
This PDU carries SDU#3. 


<— 


AMD PDU#3 


- 


- 


14 


The UE transmits an AMD PDU which carries 
SDU#2. 


— > 


AMD PDU (SN=2) 


- 


- 


15 


The SS transmits a STATUS PDU. This PDU 
nacks the 10 bytes and the last 30 bytes in the 
AMD PDU with SN=2. NACK_SN=2 with 
SOStart=50 and SOEnd=59, resp. SOStart=70 
and SOEnd='FFFF'H, and ACK SN=2. 


<— 


STATUS PDU 






16a 
1 


Check: does the UE transmit an AMD PDU 
segment with SO=50, LSF=0 and the same 
content at the requested positions as in the 
original AMD PDU? 


— > 


AMD PDU#3 segment 1 (SN=2) 


1 


P 


16a 
2 


Check : does the UE transmit and AMD PDU 
segment with SO =70, LSF=1 and the same 
content at the requested positions as in the 
original AMD PDU? 


— > 


AMD PDU#3 segment 2 (SN=2) 


1 


P 


16b 


Check: does the UE transmit an AMD PDU 
segment with SO=50, LSF=0 and the same 
content at the requested positions as in the 
original AMD PDU? 


— > 


AMD PDU#3 segment 1 (SN=2) 


1 


P 


17 


The SS transmits a STATUS PDU with 
SN ACK=3. 


<— 


STATUS PDU 


- 


- 
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Editor's note: Steps 16al, 16a2 and 16b should be updated so as to use a IF/THEN statement (e.g. by having one 
step only for 16al and 16b, then 16a2 would be conditional to LSF received in step 16al). 



7.2.3.17.3.3 Specific message contents 

None. 

7.2.3.1 8 AM RLC / Reassembly / AMD PDU reassembly from AMD PDU segments; 
Segmentation Offset and Last Segment Flag fields 

7.2.3.1 8.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives AM PDUs segments } 

then { UE delivers reassembled RLC SDU to upper layer} 
} 

(2) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives RLC AM PDUs segments without segment header extension part } 
then { UE correctly handles RLC AMD PDU segments } 
} 

(3) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives RLC AM PDUs segments with segment header extension part } 
then { UE correctly handles RLC AMD PDU segments } 
} 

(4) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives duplicate RLC AM PDU segments } 
then { UE discards duplicate RLC AMD PDU segments } 
} 

(5) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives RLC AM PDU segments out of sequence } 
then { UE delivers reassembled RLC SDU to upper layer } 
} 

(6) 

with { UE in E-UTRAN RRC_CONNECTED state } 
ensure that { 

when { UE receives RLC AMD PDU segments with a gap } 

then { UE transmits STATUS PDU to request retransmission of missing segments } 
} 

7.2.3.18.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.322 clauses 
4.2.1.3.3, 6.2.1.4 and 6.2.1.5. 

[TS 36.322, clause 4.2.1.3.3] 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 
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detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data 
PDUs; 

reorder the RLC data PDUs if they are received out of sequence; 

detect the loss of RLC data PDUs at lower layers and request retransmissions to its peer AM RLC entity; 

reassemble RLC SDUs from the reordered RLC data PDUs and deliver the RLC SDUs to upper layer in 
sequence. 

[TS 36.322, clause 6.2.1.4] 

AMD PDU consists of a Data field and an AMD PDU header. 

AMD PDU header consists of a fixed part (fields that are present for every AMD PDU) and an extension part (fields 
that are present for an AMD PDU when necessary). The fixed part of the AMD PDU header itself is byte aligned and 
consists of a D/C, a RF, a P, a FI, an E and a SN. The extension part of the AMD PDU header itself is byte aligned and 
consists of E(s) and LI(s). 

An AMD PDU header consists of an extension part only when more than one Data field elements are present in the 
AMD PDU, in which case an E and a LI are present for every Data field element except the last. Furthermore, when an 
AMD PDU header consists of an odd number of LI(s), four padding bits follow after the last LI. 

[TS 36.322, clause 6.2.1.5] 

AMD PDU segment consists of a Data field and an AMD PDU segment header. 

AMD PDU segment header consists of a fixed part (fields that are present for every AMD PDU segment) and an 
extension part (fields that are present for an AMD PDU segment when necessary). The fixed part of the AMD PDU 
segment header itself is byte aligned and consists of a D/C, a RF, a P, a FI, an E, a SN, a LSF and a SO. The extension 
part of the AMD PDU segment header itself is byte aligned and consists of E(s) and LI(s). 

An AMD PDU segment header consists of an extension part only when more than one Data field elements are present 
in the AMD PDU segment, in which case an E and a LI are present for every Data field element except the last. 
Furthermore, when an AMD PDU segment header consists of an odd number of LI(s), four padding bits follow after the 
last LI. 



Test description 
Pre-test conditions 



7.2.3.18.3 




7.2.3.18.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18] with a loop back size of 102 bytes. 
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7.2.3.18.3.2 



Test procedure sequence 



Table 7.2.3.18.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 


1 


The SS transmits an AMD PDU of 50 data 
bytes. This PDU carries the 1 " part of SDU#1 . 
This PDU is in error and to be discarded by the 
UE. 


<— 


AMD PDU#1 






2 


The SS transmits an AIVID PDU of 100 data 
bytes. The P-bit is set. This PDU carries 
SDU#2. 


<— 


AMD PDU#2 






3 


The UE transmits a STATUS PDU NACK SN 
field for missing PDU#1.ACK SN=2, 
NACK SN=0. 


— > 


STATUS PDU 






4 


The SS transmits an AIVID PDU of 50 data 
bytes. This PDU carries segment lof PDU#1. 
SO=0 and LSF=0. 


<— 


AMD PDU#1 
segment 1 






5 


The SS transmits an AIVID of 50 data bytes. 
This PDU carries segment 2 of PDU 1 . 
SO=[tbd] and LSF=1 . The P-bit is set. 


<— 


AMD PDU #1 
segment 2 






6 


Check: does the UE transmit a STATUS PDU 
ACK_SN field for the receipt of PDUs up to 2? 
NACK SN not provided. 


— > 


STATUS PDU 


2 


P 


7 


Check: does the UE transmit RLC SDU#1 ? 


-> 


(RLCSDU#1) 


1 


P 


8 


Check: does the UE transmit RLC SDU#2? 


-> 


(RLC SDU#2) 


1 


P 


9 


The SS transmits an AMD PDU of 100 data 
bytes. The P-bit is set. This PDU carries 
SDU#4. 


<— 


AMD PDU#4 






10 


Check: does the UE transmit a STATUS PDU 
NACK SN field for receipt of PDU#3? 


— > 


STATUS PDU 


5 


P 


11 


The SS transmits an AMD PDU of 50 data 
bytes to the UE. This PDU carries segment lof 
PDU#3. SO=0 and LSF=0. PDU#3 contains 
SDU#3. 


<— 


AMDPDU#3(P=1) 
segment 1 






12 


Check: does the UE transmit a STATUS PDU 
with NACK SN=3, 
SOStart=50/SOEnd='FFFF'H? 


— > 


STATUS PDU 


3,6 


P 


13 


The SS transmits an AMD PDU of 50 data 
bytes. This PDU carries segment lof PDU#3. 
SO=0 and LSF=0. 


<— 


AMD PDU#3 
segment 1 






14 


The SS transmits one RLC PDU of 50 data 
bytes. This PDU carries segment 2 of PDU#3. 
SO=50 and LSF=1 . The P-bit is set. 


<— 


AMD PDU#3 
segment 2 






15 


Check: does the UE transmit a STATUS PDU 
ACK SN field for receipt of PDUs up to 4? 
NACK SN not provided. 


— > 


STATUS PDU 


4 


P 


16 


Check: does the UE transmit RLC SDU#3? 


-> 


RLC SDU#3 


1 


P 


17 


Check: does the UE transmit RLC SDU#4? 


-> 


RLC SDU#4 


1 


P 


18 


The SS transmits an AMD PDU of 50 data 
bytes. This PDU carries part 2 of PDU#6 SO 
=50, LSF=1.The P-bit is set. 


<— 


AMD PDU#6 
segment 2 






19 


Check: does the UE transmit a STATUS PDU 
NACK_SN, E1/E2 field for receipt of PDU#5 
and SOStart=0/SOEnd=49 for segment 1 of 
PDU6? 


— > 


STATUS PDU 


6 


P 


20 


The SS transmits an AMD PDU of 100 data 
bytes. This PDU carries segment 2 of PDU#5. 
SO=0 and LSF=0, E, LI field. 


<— 


AMD PDU#6 
segment 1 






21 


The SS transmits one RLC PDU of 100 data 
bytes. This PDU carries segments land 2 of 
PDU#5. Fl=00, SO=0 and LSF=1, E, Ll=50. 


<— 


AMD PDU 5 
segment 1 






22 


Check: does the UE transmit a STATUS PDU 
acking receipt of PDUs up to 6? NACK_SN not 
provided. 


— > 


STATUS PDU 


3,5 


P 


23 


Check: does the UE transmit RLC SDU#5? 


-> 


(RLC SDU#5) 


1 


P 
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24 I Check: does the UE transmit RLC SDU#6? | --> | (RLC SDU#6) I 1 I P I 

Editor's note: Steps 6, 14 and 22 should be clarified (does the SS check that "NACK_SN" is absent ?). 

Editor's note: In the table above, wordings such as "ACK_SN field for receipt of, "NACK_SN for receipt of", etc, 
should be replaced with actual values. 

Editor's note: In step 20, "E, LI field" should be clarified. 

7.2.3.18.3.3 Specific message contents 

None. 

7.2.3.19 AM RLC / Duplicate detection of RLC PDU segments 

7.2.3.1 9.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives a RLC data PDU within an AMD PDU segment where byte segments of the original 
AMD PDU contained in the RLC data PDU have been received before } 

then { the UE discards the duplicate byte segments } 
} 

7.2.3.19.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.322, clause 5.1.3.2.2. 

[TS 36.322, clause 5.1.3.2.2] 

When a RLC data PDU is received from lower layer, where the RLC data PDU contains byte segment numbers y to z of 
an AMD PDU with SN = x, the receiving side of an AM RLC entity shall: 

if X falls outside of the receiving window; or 

if byte segment numbers y to z of the AMD PDU with SN = x have been received before: 

discard the received RLC data PDU; 
else: 

place the received RLC data PDU in the reception buffer; 

if some byte segments of the AMD PDU contained in the RLC data PDU have been received before: 

- discard the duplicate byte segments. 

Test description 
Pre-test conditions 



7.2.3.19.3 




7.2.3.19.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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The UL RLC SDU size is configured to be the same as received in DL RLC SDUs. 

7.2.3.1 9.3.2 Test procedure sequence 

Editor's note: The method to make AMD PDU header invahd is TBD in the test sequence below. 

Table 7.2.3.19.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS creates 1 RLC SDU of size 100 bytes using 
5 SDU segments denoted a to e of each 20 
bytes. The SS transmits an AMD PDU 
segment with poll bit enabled and SN = 
containing SDU segment a to c. (Note 1 ) 


<— 


AMD PDU segment ((AMD PDU 
Segment header(P='1',SN='0', 
LSF='1',SO='0' bytes, Ei='1', 
Lli='20', E2='1', Ll2='20', E3='0', 
Ll3='20'), SDU segment a to c) 






2 


The UE transmits a STATUS PDU. 


— > 


STATUS PDU 


- 


- 


3 


SS ignores ACK of AIVID PDU Segment and 
resends it. (Note 2) 


<— 


AMD PDU segment ((AMD PDU 
Segment header(SN='0', LSF='1', 
SO='0' bytes, E1='1', LI1='20', 
E2='1', LI2='20', E3='0', LI3='20'), 
SDU segment a to c) 


1 




4 


SS sends another AMD PDU segment#2 with 
SN =0 with byte segment numbers d to e. 


<— 


AMD PDU segment ((AMD PDU 
Segment header(SN='0', LSF='1', 
SO='60' bytes, Ei='1', Lli='20', 
E2='0', Ll2='20'), SDU segment d 
toe) 


1 




5 


Check: Does UE transmit a RLC SDU with 
same content correspondent to SDU segments 
a to e as created in step 1 ? 


— > 


(RLC SDU) 


1 


P 


6 


SS creates 1 RLC SDU of size 100 bytes using 
5 SDU segments denoted a to e of each 20 
bytes. The SS transmits the SDU byte 
segments a to d in an AMD PDU segment with 
poll bit enabled and SN=1 . (Note 1 ) 


<— 


AMD PDU segment ((AMD PDU 
Segment header(P='1', SN='1', 
LSF='0', SO='0' bytes, Ei='1', 
Lli='20', E2='1', Ll2='20', E3='1', 
Ll3='20' , E4='0', Ll4='20'),SDU 
segment a to d) 






7 


UE transmits a STATUS PDU. 


-> 


STATUS PDU 


- 


- 


8 


SS ignores ACK of AMD PDU Segment sent in 
step 5 and resends it. 


<— 


AMD PDU segment ((AMD PDU 
Segment header(SN='1', LSF='0', 
SO='0' bytes, Ei='1', Lli='20', 
E2='r, Ll2='20', E3='1', 
Ll3='20'),SDU segment a to d) 






9 


The SS transmits the SDU byte segments a to 
b in an AMD PDU segment with SN=1 . (Note 
2) 


<— 


AMD PDU segment ((AMD PDU 
Segment header(SN='1', LSF='0', 
SO='0' bytes, Ei='1', Lli='20', 
E2='0', Ll2='20'),SDU segment a to 
b) 


1 




10 


The SS transmits the SDU byte segments c to 
e in an AMD PDU segment with SN=0. 


<— 


AMD PDU segment ((AMD PDU 
Segment header(SN='1', LSF='0', 
SO='40' bytes, Ei='1', Lli='20', 
E2='1', Ll2='20',E3='0', Ll3='20'), 
SDU segments c to e). 






11 


Check: Does UE transmit a RLC SDU with 
same content correspondent to SDU segments 
a to e as created in step 5? (Note 2) 


— > 


(RLC SDU) 


1 


P 


Note 1 . PDU segments are used when a PDU needs to be retransmitted and the available transport block size has 

changed since the original transmission. 
Note 2. The duplicated AIVID data PDUs/AMD segments are discarded by the UE. 



7.2.3.19.3.3 
None. 



Specific message contents 



7.2.3.20 AM RLC / Duplicate detection of RLC PDUs 

Editor's note: this test case description is not based on 36.322 v8.3.0. 
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7.2.3.20.1 

(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is in AM mode and receives duplicated RLC data PDUs having the same sequence number} 

then { UE discards the duplicated RLC data PDUs } 

} 

7.2.3.20.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.322, clause 4.2.1.3.3. 

[TS 36.322, clause 4.2.1.3.3] 

When the receiving side of an AM RLC entity receives RLC data PDUs, it shall: 

detect whether or not the RLC data PDUs have been received in duplication, and discard duplicated RLC data 
PDUs; 



7.2.3.20.3 


Test description 


7.2.3.20.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 

The UL RLC SDU size is configured to be the same as received in DL RLC SDUs. 

Editor's note: UL RLC SDU size is not a parameter of the generic procedure to bring the UE in test state Loopback 
Activated. The statement on UL RLC SDU size shall be removed if the default scheduling policy can be 
used. 
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7.2.3.20.3.2 



Test procedure sequence 



Table 7.2.3.20.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS creates 3 RLC SDUs of size 40 byes 
segmented into two AMD PDUs each. AMD 
PDU#1 and AMD PDU#2 belongs to RLC 
SDU#1 , AMD PDU#3 and #4 belongs to RLC 
SDU#2 and AMD PDU#5 and #6 belongs to 
RLC SDU#3. 

SS transmits AMD PDU#1 with SN=0, AMD 
PDU#2 with SN=1 and AMD PDU#3 twice with 
SN=2. 


<— 


RLC AMD PDU#1 (SN=0) 
RLCAMDPDU#2(SN=1) 
RLC AMD PDU#3 (SN=2) 
RLC AMD PDU#3 (SN=2) 


1 




2 


Check: Does UE transmit RLC SDU#1 ? 
(Note 1) 


— > 


(RLCSDU#1) 


1 


P 


3 


SS transmits AMD PDU#4 with SN=3. 


<— 


RLC AMD PDU#4 (SN=3) 


1 


- 


4 


Check: Does UE transmit RLC SDU#2? 


— > 


(RLC SDU#2) 


1 


P 


5 


SS transmits AMD PDU#6 twice with SN=5. 


<— 


RLC AMD PDU#6 (SN=5) 
RLC AMD PDU#6 (SN=5) 


1 




6 


SS transmits AMD PDU#5 twice with SN=4. 


<— 


RLC AMD PDU#5 (SN=4) 
RLC AMD PDU#5 (SN=4) 


1 


- 


7 


Check: Does UE transmit RLC SDU#3 once? 
(Note 2) 


— > 


(RLC SDU#3) 


1 


P 


Note 1 The duplicated AMD PDU#3 have been discarded by the conformant UE in step 1 . 
Note 2 The duplicated AMD PDU#5 and AMD PDU#6 have been discarded by the conformant UE in steps 5 and 
6. 



7.2.3.20.3.3 
None. 



Specific message content 



7.3 



PDCP 



7.3.1 Maintenance of PDCP sequence numbers for radio bearers 

7.3.1 .1 Maintenance of PDCP sequence numbers (user plane, RLC AM) 

7.3.1.1.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE transmits a PDCP Data SDU } 

then { UE increments SN with 1 for each transmitted PDU for SN=0 to Maximum_PDCP_SN } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE transmits a PDCP Data SDU and Next_PDCP_TX_SN reach the Maximum_PDCP_SN limit 
then { UE sets SN to in the next transmitted PDCP SDU} 



7.3.1.1.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clause 5.1.1 
and 5.1.2.1. 
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[TS 36.323, clause 5.1.1] 

At reception of a PDCP SDU from upper layers, the UE shall: 

- associate the PDCP SN corresponding to Next_PDCP_TX_SN to this PDCP SDU; 
start the Discard_Timer associated with this PDCP SDU (if configured); 

perform header compression of the PDCP SDU (if configured) as specified in the subclause 5.5.4; 

perform integrity protection (if applicable), and ciphering (if applicable) using COUNT based on TX_HFN and 
the PDCP SN associated with this PDCP SDU as specified in the subclause 5.7 and 5.6, respectively; 

- increment Next_PDCP_TX_SN by one; 

- if Next_PDCP_TX_SN > Maximum_PDCP_SN: 

- set Next_PDCP_TX_SN to 0; 
increment TX_HFN by one; 

submit the resulting PDCP Data PDU to lower layer. 
[TS 36.323, clause 5.1.2.1] 
For DRBs mapped on RLC AM, at reception of a PDCP Data PDU from lower layers, the UE shall: 

- if received PDCP SN - Last_Submitted_PDCP_RX_SN > Reordering_Window or <= 
Last_Submitted_PDCP_RX_SN - received PDCP SN < Reordering_Window: 

- if received PDCP SN > Next_PDCP_RX_SN : 

decipher the PDCP PDU as specified in the subclause 5.6, using COUNT based on RX_HFN - 1 and the 
received PDCP SN; 

else: 

decipher the PDCP PDU as specified in the subclause 5.6, using COUNT based on RX_HFN and the 
received PDCP SN; 

perform header decompression (if configured) as specified in the subclause 5.5.5; 

- discard this PDCP SDU; 

- else if Next_PDCP_RX_SN - received PDCP SN > Reordering_Window: 

increment RX_HFN by one; 

- use COUNT based on RX_HFN and the received PDCP SN for deciphering the PDCP PDU; 

- set Next_PDCP_RX_SN to the received PDCP SN + 1; 

- else if received PDCP SN - Next_PDCP_RX_SN > Reordering_Window: 

- use COUNT based on RX_HFN - 1 and the received PDCP SN for deciphering the PDCP PDU; 

- else if received PDCP SN >= Next_PDCP_RX_SN: 

- use COUNT based on RX_HFN and the received PDCP SN for deciphering the PDCP PDU; 

- set Next_PDCP_RX_SN to the received PDCP SN + 1 ; 

- if Next_PDCP_RX_SN is larger than Maximum_PDCP_SN: 

- set Next_PDCP_RX_SN to 0; 
increment RX_HFN by one; 

- else ifreceived PDCP SN< Next PDCP RX SN: 
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- use COUNT based on RX_HFN and the received PDCP SN for deciphering the PDCP PDU; 

if the PDCP PDU has not been discarded in the above: 

perform deciphering and header decompression (if configured) for the PDCP PDU as specified in the 
subclauses 5.6 and 5.5.5, respectively; 

- if a PDCP SDU with the same PDCP SN is stored: 

- discard this PDCP SDU; 
else: 

- store the PDCP SDU; 

if the PDCP PDU received by PDCP is not due to the re-establishment of lower layers: 

deliver to upper layers in ascending order of the associated COUNT value: 

all stored PDCP SDU(s) with an associated COUNT value less than the COUNT value associated with 
the received PDCP SDU; 

all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value 
associated with the received PDCP SDU; 

- set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers; 

- else if received PDCP SN = Last_Submitted_PDCP_RX_SN + 1 : 

deliver to upper layers in ascending order of the associated COUNT value: 

all stored PDCP SDU(s) with consecutively associated COUNT value(s) starting from the COUNT value 
associated with the received PDCP SDU; 

- set Last_Submitted_PDCP_RX_SN to the PDCP SN of the last PDCP SDU delivered to upper layers. 
7.3.1.1.3 Test description 

7.3.1.1.3.1 Pre-test conditions 

System Simulator 

- Cell 1 

- SS PDCP set to Transparent Mode 

UE: 
None. 

Preamble 

- The UE is in state Loopback Activated (state 4) according to [18]. 
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7.3.1.1.3.2 



Test procedure sequence 



Table 7.3.1.1.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 




- 


EXCEPTION: Steps 1 and 2 shall be repeated 
for k=0 to Maximum PDCP SN (incremental). 










1 


SS transmits a PDCP Data PDU on DRB1 
containing one IP packet without header 
compression. 


<— 


PDCP Data PDU (SN = k) 






2 


CHECK: Does UE transmit a PDCP Data PDU 
with SN=0 for the first iteration and then 
incremented by 1 at each iteration? 


— > 


PDCP Data PDU (SN = k) 


1 


P 


3 


SS transmits a PDCP Data PDU on DRB1 
containing one IP packet without header 
compression. 


<— 


PDCP Data PDU (SN = 0) 






4 


CHECK: Does UE transmit a PDCP Data PDU 
with SN=0? 


— > 


PDCP Data PDU (SN = 0) 


2 


P 


5 


SS sends a PDCP Data PDU on DRB1 
containing one IP packet without header 
compression. 


<— 


PDCP Data PDU (SN = 1) 






6 


CHECK: Does UE transmit a PDCP Data PDU 
withSN=1? 


— > 


PDCP Data PDU (SN = 1) 


1 


P 



7.3.1.1.3.3 
None 



Specific message contents 



7.3.4 PDCP Integrity Protection 



7.3.4.1 



7.3.4.1.1 



Integrity protection: Correct functionality of EPS AS integrity algorithms 
(SN0W3G) 

Test Purpose (TP) 



(1) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is requested to achieve functionality of EPS AS integrity algorithms with SN0W3G} 

then { UE performs the integrity protection function in PDCP entities associated with SRBs . } 
} 

7.3.4.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clauses 5.4 

[TS 36.323, clause 5.4] 

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP 
for PDCP entities associated with SRBs. 

The integrity protection algorithm and key to be used for PDCP entities are the ones configured by upper layers for each 
received PDCP PDU [3] and the integrity protection method shall be applied as specified in [6]. 

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection 
function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the 
downlink and the uplink, respectively. 

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the 
configuration included in this RRC message, this message needs first be decoded by RRC before the 
integrity protection verification could be performed for the PDU in which the message was received. 
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The parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity 
protection algorithm. The parameters required by PDCP which are provided by upper layers [3] are listed below: 

BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity -1 as in [3]); 

DIRECTION (direction of the transmission: for uplink, 1 for downlink); 

IK (Integrity Protection Key). 

At transmission, the UE computes the value of the MAC -I field and at reception it verifies the integrity of the PDCP 
PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC 
corresponds to the received MAC-I, integrity protection is verified successfully, otherwise the interaction with upper 
layers is FES. 

The data unit that is integrity protected is the unciphered data part of the PDU and the PDU header. 
Test description 
Pre-test conditions 



7.3.4.1.3 




7.3.4.1.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Registered, Idle Mode (State 2) according to [18]. 
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7.3.4.1.3.2 



Test procedure sequence 



Table 7.3.4.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS sends a Paging message to the UE on the 
appropriate paging block, and including the UE 
identity in one entry of the IE 
pagingRecordLists. 




Paging 






2 


UE transmits an RRCConnectionRequest 
message. The MAC-I of this message related 
PDCP Data PDU should be set to 0. 


— > 


RRCConnectionRequest 






3 


SS transmit an RRCConnectionSetup 
message. The MAC-I of this message related 
PDCP Data PDU should be set to 0. 


<— 


RRCConnectionSetup 






4 


The UE transmits an 

RRCConnectionSetupComplete message to 
confirm the successful completion of the 
connection establishment and to initiate the 
session management procedure by including 
the SERVICE REQUEST message. The MAC- 
1 of this message related PDCP Data PDU 
should be set to 0. 


— > 


RRCConnectionSetupComplete 






5 


The SS transmits a SecurityModeCommand 
message to activate AS security with 
SN0W3G integrity algorithms protected. The 
IVIAC-I of this message related PDCP Data 
PDU is set to an authentication code. 


<— 


SecurityModeCommand 






6 


Check; Does the UE transmit a 
SecurityModeComplete message and 
establishes the initial security configuration. 
The IVIAC-I of this message related PDCP 
Data PDU is set to an authentication code. 


-> 


SecurityModeComplete 


1 


P 


7 


Check: Does the SecurityModeComplete 
message from UE passes the SS' integrity 
protection check? 






1 


P 



7.3.4.1.3.3 



Specific message contents 

Table 7.3.4.1.4-1 SecurityModeCommand message (step 6) 



Derivation Path: 36.331 clause 6.2.2 


Information Element 


Value/remark 


Comment 


Condition 


SecuritylVlodeCommand ::= SEQUENCE { 








rrc-Transactionldentifier 


RRC- 

Transaction Identifier-DL 






criticalExtensions CHOICE { 








c1 CHOICE! 








securitylVlodeCommand-r8 SEQUENCE { 








securityConfiguration SEQUENCE { 








IntegrityProtAlgorithm 


FFS 






cipheringAlgorithm 


FFS 






keylndicator 


Not present 






} 
















1 








} 








} 








} 
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7.3.4.2 Integrity protection: Correct functionality of EPS AS integrity algorithms (AES) 

7.3.4.2.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is requested to achieve functionality of EPS AS integrity algorithms with AES } 

then { UE performs the integrity protection function in PDCP entities associated with SRBs . } 
} 

7.3.4.2.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clauses 5.4 

[TS 36.323, clause 5.4] 

The integrity protection function includes both integrity protection and integrity verification and is performed in PDCP 
for PDCP entities associated with SRBs. 

The integrity protection algorithm and key to be used for PDCP entities are the ones configured by upper layers for each 
received PDCP PDU [3] and the integrity protection method shall be applied as specified in [6]. 

The integrity protection function is activated by upper layers [3]. After security activation, the integrity protection 
function shall be applied to all PDUs including and subsequent to the PDU indicated by upper layers [3] for the 
downlink and the uplink, respectively. 

NOTE: As the RRC message which activates the integrity protection function is itself integrity protected with the 
configuration included in this RRC message, this message needs first be decoded by RRC before the 
integrity protection verification could be performed for the PDU in which the message was received. 

The parameters that are required by PDCP for integrity protection are defined in [6] and are input to the integrity 
protection algorithm. The parameters required by PDCP which are provided by upper layers [3] are listed below: 

BEARER (defined as the radio bearer identifier in [6]. It will use the value RB identity -1 as in [3]); 

DIRECTION (direction of the transmission: for uplink, 1 for downlink); 

IK (Integrity Protection Key). 

At transmission, the UE computes the value of the MAC -I field and at reception it verifies the integrity of the PDCP 
PDU by calculating the X-MAC based on the input parameters as specified above. If the calculated X-MAC 
corresponds to the received MAC-I, integrity protection is verified successfully, otherwise the interaction with upper 
layers is FES. 

The data unit that is integrity protected is the unciphered data part of the PDU and the PDU header. 



7.3.4.2.3 


Test description 


7.3.4.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in Registered, Idle Mode (State 2) according to [18]. 
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7.3.4.2.3.2 



Test procedure sequence 



Table 7.3.4.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS sends a Paging message to the UE on the 
appropriate paging block, and including the UE 
identity in one entry of the IE 
pagingRecordLists. 


<— 


Paging 






2 


UE transmits an RRCConnectionRequest 
message. The MAC-I of this message related 
PDCP Data PDU should be set to 0. 


— > 


RRCConnectionRequest 






3 


SS transmit an RRCConnectionSetup 
message. The MAC-I of this message related 
PDCP Data PDU should be set to 0. 


<— 


RRCConnectionSetup 






4 


The UE transmits an 

RRCConnectionSetupComplete message to 
confirm the successful completion of the 
connection establishment and to initiate the 
session management procedure by including 
the SERVICE REQUEST message. (StateS) 
The MAC-I of this message related PDCP 
Data PDU should be set to 0. 


— > 


RRCConnectionSetupComplete 






5 


The SS transmits a SecurityModeCommand 
message to activate AS security with AES 
integrity algorithms protected and without 
Ciphering. The MAC-I of this message related 
PDCP Data PDU is set to an authentication 
code. 


<— 


SecurityModeCommand 






6 


Check: does the UE transmits a 
SecurityModeComplete message and 
establishes the initial security configuration. 
The MAC-I of this message related PDCP 
Data PDU is set to an authentication code? 


— > 


SecurityModeComplete 


1 


P 


7 


Check: does the SecurityModeComplete 
message from UE passes the SS' integrity 
protection check and can be submitted to RRC 
layer? 






1 


P 



7.3.4.2.3.3 



Specific message contents 



Table 7.3.4.2.4-1 SecurityModeCommand message (step 6) 



Derivation Path: 36.331 clause 6.2.2 


Information Element 


Value/remark 


Comment 


Condition 


SecurityModeCommand ::= SEQUENCE { 








rrc-Transactionldentifier 


RRC- 

Transaction Identifier-DL 






criticalExtensions CHOICE { 








c1 CHOICE! 








securityModeCommand-r8 SEQUENCE { 








securityConfiguration SEQUENCE { 








IntegrityProtAlgorithm 


FFS 






cipheringAlgorithm 


FFS 






keylndicator 


Not present 






} 
















} 








1 








} 








} 
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7.3.5 PDCP - Handover 

7.3.5.1 PDCP handover / Lossless Handover / Retransmission of PDCP SDU in the 

uplink 

7.3.5.1.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE is requested to make a handover by SS } 
then { UE re-transmits uplink PDCP SDUs } 
} 

7.3.5.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clauses 5.5.1.3 

The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.323, clause 5.5.1.3] 

When upper layers indicate that a handover has occurred, for radio bearers that are mapped on RLC AM the UE shall: 

re-transmit all uplink PDCP SDUs starting from the first PDCP SDU for which the successful delivery of the 
corresponding PDCP PDU has not been confirmed by lower layers; 

perform header compression if applicable and ciphering as specified in subclauses 5.2 and 5.3 on the PDCP 
SDUs. 

7.3.5.1 .3 Test description 

7.3.5.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 

ROHC is not used for headerCompression settings. 

UE: 
None. 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
ROHC is not used, according to table 7.3.5.1.3.1-1. 

Table 7.3.5.1.3.1-1: headerCompression settings 

Parameter Value 

notUsed NULL 
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7.3.5.1.3.2 



Test procedure sequence 



Table 7.3.5.1.3.2-1 Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS creates a PDCP Data PDU. The 
Next PDCP TX SN is set to "0". 


- 


- 


- 


- 


2 


The SS is configured no RLC ACK to the UE. 


- 


- 


- 


- 


3 


The SS sends the PDCP Data PDU via RLC- 
Al\/I RB with the following content to the UE: 
D/C field = 1 (PDCP Data PDU) 
After having send a PDU, the SS increments 
its counter value Next PDCP TX SNby"1". 


<— 


PDCP DATA 






4 


Check if the UE sends a PDCP Data PDU via 

RLC-AIVI RB with the following content back to 

the SS: 

D/C field = 1 (PDCP Data PDU) 

data: previously received packet 


— > 


PDCP DATA 






5 


The SS requests UE to make a handover with 
the RRCConnectionReconfiguration message. 


- 


- 


- 


- 


6 


The UE transmits a 

RRCConnectionReconfigurationComplete 

message. 










7 


Check: does the transmit a PDCP SDU in the 
PDCP Data PDU via RLC-AM RB with the 
following content back to the SS: 
D/C field = 1 (PDCP Data PDU) 
data: previously received packet? 


— > 


PDCP DATA 


1 


P 



7.3.5.1.3.3 Specific message contents 

Table 7.3.5.1.3.3-1 RRCConnectionReconfiguration (Step 5, 7.3.5.1.3.2-1) 



FFS 



FFS 



Table 7.3.5.1.3.3-2 RRCConnectionReconfigurationComplete (Step 6, 7.3.5.1.3.2-1) 



7.3.5.2 PDCP handover / Lossless handover / PDCP Sequence Number 

maintenance 

Editor's note: this test case description is not based on 36.323 v8.3.0. 

7.3.5.2.1 Test Purpose (TP) 
(1) 

with {UE in E-UTRA RRC_CONNECTED state with default RB using RLC-AM} 
ensure that { 

when { UE is requested to make a lossless handover by SS } 
then { UE retransmits the unacknowledged data} 
} 

7.3.5.2.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clause 5.5.1.1. 
[TS 36.323, clause 5.5.1.1] 

When upper layers indicate that a handover has occurred, for radio bearers that are mapped on RLC AM, the UE shall: 
- start the Flush_Timer 
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perform maintenance of PDCP sequence numbers, header decompression and deciphering as indicated in 
subclauses 5.1.1.1, 5.2 and 5.3 for PDCP PDUs received from lower layers and store the out-of-sequence PDCP 
SDUs, if any, in the reordering buffer until it is indicated to submit them to upper layers (Note these SDU are 
received because of the reset of the lower layer). 

- if (Next_PDCP_RX_SN - Reordering_Window) modulo 4096 > Next_PDCP_RX_SN: 

decrease the value of RX_HFN by one; 

- set the variable Next_PDCP_RX_SN to (Next_PDCP_RX_SN - Reordering_Window) modulo 4096; 

if the radio bearer is configured by upper layers to send a PDCP status report, compile a status report as indicated 
below and submit it to lower layers as the first PDCP PDU for the transmission, by: 

- setting the FMS field to the PDCP Sequence Number of the first missing PDCP SDU; 

if there are more than one missing PDCP SDUs, allocating a Bitmap field of length in bits equal to the 
number of PDCP Sequence Numbers from and not including the first missing PDCP PDU up to and 
including the last out-of-sequence PDCP PDU, rounded up to the next multiple of 8; 

setting as '0' in the corresponding position in the bitmap field all PDCP SDUs that have not been received as 
indicated by lower layers and optionally, PDCP PDUs for which decompression has failed; 

indicating in the bitmap field as '1' all other PDCP SDUs. 

reset the header compression protocol in the transmitting and receiving sides of the PDCP entity; 

perform in-order delivery and duplicate elimination in the downlink as specified in subclause 5.5.1.2.1 until the 
reordering function is finished as indicated in 5.5.1.2.2; 

perform re-transmission of PDCP SDUs in the uplink as specified in subclause 5.5.1.3. 
7.3.5.2.3 Test description 

7.3.5.2.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 and Cell 2 

UE: 
None. 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.3.5.2.3.2 



Test procedure sequence 



Table 7.3.5.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS creates a TCP/IP packet without IP 
header compression. The Next_PDCP_TX_SN 
is set to "0". 










2 


The SS sends a PDCP Data PDU via RLC-AIVI 
RB with the following content to the UE: 
D/C field = 1 (PDCP Data PDU) 
Afterwards the SS increments its counter value 
Next PDCP TX SNby"1". 


<— 


PDCP DATA 






3 


Check if the UE sends a PDCP Data PDU via 

RLC-AIVI RB with the following content back to 

the SS: 

D/C field = 1 (PDCP Data PDU) 

data: previously received TCP/IP packet 


— > 


PDCP DATA 


1 


P 


4 


The SS does not send the RLC ACK to the UE 


- 


- 


- 


- 


5 


SS generates the 

RRCConnectionReconfiguration message as 
signalled to the UE (parameter values as used 
in RRC testing). 


<— 


RRCConnectionReconfiguration 






6 


Check if UE has completed the RRC 
connection reconfiguration. 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


7 


Check if the UE retransmits a PDCP Data PDU 

via RLC-AIVI RB with the following content 

back to the SS: 

D/C field = 1 (PDCP Data PDU) 

data: previously received TCP/IP packet 


— > 


PDCP DATA 


1 


P 



7.3.5.2.3.3 Specific message contents 

Table 7.3.5.2.3.3-1 RRCConnectionReconfiguration (step 4, Table 7.3.5.2.3.2-1) 



FFS 



FFS 



Table 7.3.5.2.3.3-2 RRCConnectionReconfigurationComplete {step 5, Table 7.3.5.2.3.2-1) 



7.3.5.3 PDCP handover/Non-lossless handover PDCP Sequence Number 

maintenance 

Editor's note: this test case description is not based on 36.323 v8.3.0. 

Editor's note: This test case should be updated according to CRs in RP-080412. Especially, test purpose and test 
sequence may be affected by CR3rl in RP-080412 (new section is added so that UE re-numbers not- 
discarded PDCP SDUs). 



7.3.5.3.1 
(1) 



Test Purpose (TP) 



with {UE in E-UTRA RRC_CONNECTED state with default bearer using RLC-UM} 
ensure that { 

when {UE is requested to make a non- lossless handover by SS} 
then { UE sets the PDCP state variable to } 
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7.3.5.3.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clauses 5.5.2.1. 

[TS 36.323, clause 5.5.2.1] 

When upper layers indicate that a handover has occurred, for DRBs mapped on RLC UM the UE shall: 

perform maintenance of PDCP sequence numbers, header decompression and deciphering as indicated in 
subclauses 5.1.1.1, 5.2 and 5.3 for PDCP PDUs received from lower layers: 

reset the header compression and de-compression protocol; 

- set the variables Next_PDCP_TX_SN, Next_PDCP_RX_SN, TX_HFN and RX_HFN to 0. 

7.3.5.3.3 Test description 
7.3.5.3.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 and Cell 2 

UE: 
None. 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
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7.3.5.3.3.2 



Test procedure sequence 



Table 7.3.5.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS creates a TCP/IP packet without IP 
header compression. The Next_PDCP_TX_SN 
is set to "0". 


— > 








2 


The SS sends a PDCP Data PDU via RLC-UM 
RB with the following content to the UE: 
D/C field = 1 (PDCP Data PDU) 
Afterwards the SS increments its counter value 
Next PDCP TX SNby"1". 


<— 


PDCP DATA 






3 


Check if the UE sends a PDCP Data PDU via 

RLC-UIVI RB with the following content back to 

the SS: 

D/C field = 1 (PDCP Data PDU) 

data: previously received TCP/IP packet 


— > 


PDCP DATA 


1 


P 


4 


SS generates the 

RRCConnectionReconfiguration message as 
signalled to the UE (parameter values as used 
in RRC testing). 


<— 


RRCConnectionReconfiguration 






5 


Check if UE has completed the RRC 
connection reconfiguration. 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


6 


The SS creates a TCP/IP packet without IP 
header compression. The Next_PDCP_TX_SN 
is set to "0". 










7 


The SS sends a PDCP Data PDU via RLC-UIVI 
RB with the following content to the UE: 
D/C field = 1 (PDCP Data PDU) 
Afterwards the SS increments its counter value 
Next PDCP TX SNby"1". 


<— 


PDCP DATA 






8 


Check if the UE sends a PDCP Data PDU via 

RLC-UIVI RB with the following content back to 

the SS: 

D/C field = 1 (PDCP Data PDU) 

data: previously received TCP/IP packet 

Check if the PDCP SN = 


— > 


PDCP DATA 


1 


P 



7.3.5.3.3 Specific message contents 

Table 7.3.5.3.3-1 RRCConnectionReconfiguration (step 4, 7.3.5.3.3.2-1) 



FFS 



Table 7.3.5.3.3-2 RRCConnectionReconfigurationComplete (Step 5, 7.3.5.3.3.2-1) 



FFS 

7.3.5.5 
7.3.5.5.1 

(1) 

with { UE in E-UTRA RRC_CONNECTED state with default RB using RLC-AM } 
ensure that { 

when { UE is requested to make a handover by SS and the timer Flush_Timer is running 
then { UE achieves in-order delivery and duplicate elimination in the downlink } 



PDCP handover / In-order delivery and duplicate elimination in the downlink 
Test Purpose (TP) 
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(2) 

with { UE in E-UTRA RRC_CONNECTED state with default RB using RLC-AM } 
ensure that { 

when { UE is requested to make a handover by SS and the timer Flush_Timer expires } 
then { UE Stops in-order delivery and duplicate elimination in the downlink } 
} 

7.3.5.5.2 Conformance requirements 

References: The conformance requirements covered in ttie present TC are specified in: 3GPP TS 36.323 clauses 5.5.1.2 
and 5.5. 1.2.2. 

[TS 36.323, clause 5.5.1.2.1] 

When a PDCP PDU associated with a PDCP Sequence Number is received from lower layers the UE shall: 

- if received PDCP Sequence Number - Last_Submitted_PDCP_RX_SN > Reordering_Window or <= 
Last_Submitted_PDCP_RX_SN - received PDCP Sequence Number < Reordering_Window: 

- if received PDCP Sequence Number > Next_PDCP_RX_SN: 

decipher the PDCP PDU according to 5.3, using COUNT based on the value of the variable RX_HFN - 1 
and the value of the PDCP Sequence Number contained in the SN field of the PDCP PDU header; 

else 

- decipher the PDCP PDU according to 5.3, using COUNT based on the value of the variable RX_HFN 
and the value of the PDCP Sequence Number contained in the SN field of the PDCP PDU header; 

perform header decompression, if configured as specified in 5.2.5; 

- discard this PDCP SDU; 

else if Next_PDCP_RX_SN - received PDCP Sequence Number > Reordering_Window: 

increment the variable RX_HFN by one; 

use the COUNT based on the value of the variable RX_HFN and the received PDCP Sequence Number 
contained in the PDCP SN field for deciphering the PDCP PDU; 

- set the variable Next_PDCP_RX_SN to received PDCP Sequence Number + 1; 

- else if received PDCP Sequence Number - Next_PDCP_RX_SN > Reordering_Window: 

use the COUNT based on the value RX_HFN - 1 and the received PDCP Sequence Number contained in the 
PDCP SN field for deciphering the PDCP PDU; 

- else if received PDCP Sequence Number >= Next_PDCP_RX_SN: 

use the COUNT based on the value of the variable RX_HFN and the received PDCP Sequence Number 
contained in the PDCP SN field for deciphering the PDCP PDU; 

- set the variable Next_PDCP_RX_SN to received PDCP Sequence Number + 1; 

- if the variable Next_PDCP_RX_SN is larger than the Maximum_PDCP_SN: 

- set the variable Next_PDCP_RX_SN to 0; 
increment the variable RX_HFN by one; 

- else if received PDCP Sequence Number < Next_PDCP_RX_SN: 

use the COUNT based on the value of the variable RX_HFN and the received PDCP Sequence Number 
contained in the PDCP SN field for deciphering the PDCP PDU; 

if the PDCP PDU has not been discarded in the above: 

perform deciphering and header decompression as indicated in subclauses 5.2 and 5.3. 
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- if a PDCP SDU with the same PDCP Sequence Number is stored: 

- discard this PDCP SDU; 
else: 

- store the PDCP SDU for later delivery; 

if the received PDCP PDU is not received due to the re-establishment of the lower layers: 
submit to upper layer in ascending order of the associated COUNT value: 

- all stored PDCP SDU(s) with an associated COUNT value less than or equal to the COUNT value 
associated with the received PDCP SDU; 

all stored PDCP SDU(s) with consecutive associated COUNT value(s) starting from the COUNT value 
associated with the received PDCP SDU + 1, if any. 

- else: 

- set the variable Last_Submitted_PDCP_RX_SN to the PDCP Sequence Number of the last PDCP SDU 
delivered to upper layers 

[TS 36.323, clause 5.5.1.2.2] 

If the timer Flush_Timer expires the UE shall: 

deactivate the in-order delivery and duplicate elimination function in the downlink 
When the in-order delivery and duplicate elimination function in the downlink is deactivated, the UE shall: 

deliver all stored PDCP SDUs in ascending order of the associated COUNT value to upper layers; 

- set the variable Last_Submitted_PDCP_RX_SN to the SN of the last PDCP SDU that was delivered to the upper 
layers; 

7.3.5.5.3 Test description 

7.3.5.5.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 and Cell 2 

ROHC is not used for headerCompression settings. 

UE: 
None. 

Preamble: 

The UE is in state Loopback Activated (state 4) according to [18]. 
ROHC is not used, according to table 7.3.5.5.3.1-1. 

Table 7.3.5.5.3.1-1: headerCompression settings 

Parameter Value 

notUsed NULL 
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7.3.5.5.3.2 



Test procedure sequence 



Table 7.3.5.5.3.2-1 Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS creates a PDCP Data PDU#0. The 
Next PDCP TX SN is set to "0". 


- 


- 


- 


- 


2 


The SS sends the PDCP Data PDU#0 via 

RLC-AIVI RB with the following content to the 

UE: 

D/C field = 1 (PDCP Data PDU) 

After having sent a PDU, the SS increments its 

counter value Next PDCP TX SNto"1". 


<— 


PDCP DATA PDU#0 






3 


Check: Does the UE transmit a PDCP Data 

PDU via RLC-AIVI RB with the following 

content back to the SS? 

D/C field = 1 (PDCP Data PDU) 

data: previously received packet in PDCP 

DATA#0 


— > 


PDCP DATA PDU 


2 


P 


4 


The SS requests UE to make a handover with 
the RRCConnectionReconfiguration message. 


- 


- 


- 


- 


5 


The UE transmits a 

RRCConnectionReconfigurationComplete 
message in the new cell. 










6 


The SS creates a PDCP Data PDU#1 . The 
Next PDCP TX SN is set to "2". 


- 


- 


- 


- 


7 


The SS sends the PDCP Data PDU#1 via 

RLC-AM RB with the following content to the 

UE: 

D/C field = 1 (PDCP Data PDU) 


<— 


PDCP DATA PDU #1 






8 


Check: Does the UE transmit a PDCP DATA 
PDU? 


— > 


PDCP DATA PDU 


1 


F 


9 


The SS creates a PDCP Data PDU#2. The 
Next PDCP TX SN is set to "2". 


- 




- 


- 


10 


The SS sends the PDCP Data PDU#2 via 

RLC-AM RB with the following content to the 

UE: 

D/C field = 1 (PDCP Data PDU) 

After having sent a PDU, the SS increments its 

counter value Next PDCP TX SN to "3". 


<— 


PDCP DATA PDU #2 






11 


Check: Does the UE transmit a PDCP DATA 
PDU? 


- 


- 


1 


P 


12 


The SS creates a PDCP Data PDU#3. The 
Next PDCP TX SN is set to "1". 


- 


- 


- 


- 


13 


The SS sends the PDCP Data PDU#3 via 

RLC-AM RB with the following content to the 

UE: 

D/C field = 1 (PDCP Data PDU) 

After having sent a PDU, the SS increments its 

counter value Next PDCP TX SN to "2". 


<— 


PDCP DATA PDU #3 






14 


Check: does the UE transmit a PDCP Data 

PDU via RLC-AM RB with the following 

content back to the SS? 

D/C field = 1 (PDCP Data PDU) 

data: previously received packet in PDCP 

DATA#3 


— > 


PDCP DATA PDU 


1 


P 


15 


Check: does the UE transmit PDCP Data PDU 

via RLC-AM RB with the following content 

back to the SS? 

D/C field = 1 (PDCP Data PDU) 

data: previously received packet in PDCP 

DATA#1 


— > 


PDCP DATA PDU 


1 


P 


16 


After Flush Timer expires, the SS creates a 
PDCP Data PDU#4. The Next_PDCP_TX_SN 
is set to "4". 










17 


The SS sends the PDCP Data PDU#4 via 


<— 


PDCP DATA PDU #4 


- 


- 
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RLC-AM RB with the following content to the 

UE: 

D/C field = 1 (PDCP Data PDU) 

After having sent a PDU, the SS increments its 

counter value Next PDCP TX SN by "5". 










18 


Check: does the UE transmit a PDCP Data 

PDU without buffering via RLC-AM RB with the 

following content back to the SS? 

D/C field = 1 (PDCP Data PDU) 

data: previously received packet in PDCP 

DATA#4 


— > 


PDCP DATA PDU #4 


2 


P 


19 


The SS creates a PDCP Data PDU#5. The 
Next PDCP TX SN is set to "4". 


- 


- 


- 


- 


20 


The SS sends the PDCP Data PDU#5 via 

RLC-AM RB with the following content to the 

UE: 

D/C field = 1 (PDCP Data PDU) 

After having sent a PDU, the SS increments its 

counter value Next PDCP TX SN to "5". 


<— 


PDCP DATA PDU #5 







Editor's note: PDCP PDU SN field value should be specified rather than Next_PDCP_TX_SN which is only an 
internal variable. 

7.3.5.5.3.3 Specific message contents 

Table 7.3.5.5.3.3-1 RRCConnectionReconfiguration (Step 4, 7.3.5.5.3.2-1) 

FFS 

Table 7.3.5.5.3.3-2 RRCConnectionReconfigurationComplete (Step 5, 7.3.5.5.3.2-1) 

FFS 

7.3.6 Others 



7.3.6.1 



PDCP Discard 



7.3.6.1.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { the Discard Timer for a PDCP SDU expires } 
then { UE discards the corresponding PDCP SDU } 
} 

7.3.6.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.323 clause 5.9. 

[TS 36.323, clause 5.9] 

When the Discard Timer expires for a PDCP SDU the UE shall discard the PDCP PDU along with the corresponding 
PDCP SDU. If the corresponding PDCP PDU has already been submitted to lower layers the discard is indicated to 
lower layers. 
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7.3.6.1.3 
7.3.6.1.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1 

- SS PDCP set to Transparent Mode 

Editor's note: The above statement shall be clarified. 

SS sets the downlink and uplink shared channel configuration transport block size (TBS) to accommodate one IP 
packet plus PDCP/RLC/MAC header without padding. 

Editor's note: The above statement is not feasible because the UE may always segment a PDCP SDU into several 
RLC PDUs. 

UE: 
None. 

Preamble 

The UE is in state Loopback Activated (state 4) according to [18] with the exceptions as specified in table 
7.3.6.1.3.1-1. 

Table 7.3.6.1.3.1-1: PDCP Settings 



Parameter 


Value 


Discard Timer 


FFS seconds 



Editor's note: Specific message contents for procedure in 36.508 shall be defined. 



7.3.6.1.3.2 



Test procedure sequence 



Table 7.3.6.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


SS sends 10 IP packets without header 
compression which are transmitted In 10 
PDCP Data PDUs on DRB1 


<— 


10 PDCP Data PDUs (SN = to 
SN = 9) 






2 


SS schedules an uplink grant to enable the UE 
to return one PDCP Data PDU in uplink 


<— 


(UL Grant) 


- 


- 


3 


CHECK: Does UE retum a PDCP Data PDU 
with SN=0? 


--> 


PDCP Data PDU (SN = 0) 


1 


P 


4 


SS waits for time equal to Dlscard_Tlmer+ 1 
TTIs and Ignores any UL scheduling requests 
from the UE. 












EXCEPTION: Steps 5 to 6 shall be repeated 
for 1 0s 


- 




- 


- 


5 


SS continuously schedules uplink grants to 
enable transmission of PDCP Data PDUs In 
uplink 




(UL Grant) 






6 


Check: does the UE transmit any PDCP Data 
PDU? 


--> 


PDCP Data PDU 


1 


F 



Editor's note: It is FFS if the monitoring of PDCP Data PDUs (steps 5 and 6) for should be replaced with checking 
that UE is not sending any scheduling requests. 
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7.3.6.1 .3.3 Specific message contents 

None. 

8 Radio Resource Control RRC 

Editor's Note: This section is based on TS 36.331 v8.2.0. + R2-083795. 

8.1 RRC Connection management procedures 

8.1.1 Paging 

8.1 .1 .1 RRC / Paging for Connection in idle mode 

Editor's note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 

8.1.1.1.1 Test Purpose (IP) 
(1) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE receives a Paging message including an IE ue-Identity set an unmatched S-TMSI i.e. other 
than the one allocated to the UE at the UE registration procedure } 
then { UE does not establish an RRC connection } 
} 

(2) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE receives a Paging message including an IE ue-Identity set to the S-TMSI which was 
allocated to the UE at the UE registration procedure } 
then { UE establishes an RRC connection } 

} 

8.1 .1 .1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.2.3, 
5.3.3.2, 5.3.3.3 and 5.3.3.4. 

[TS 36.331, clause 5.3.2.3] 

Upon receiving the Paging message, the UE shall: 

1> If in RRC_1DLE, for each of the Paging records included in the Paging message: 

2> If the ue-identity included in the pagingRecordList matches one of the UE identities allocated by upper 
layers: 

3> forward the ue-Identity, the cn-Domain and the pagingCause to the upper layers. 

[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in 
RRCJDLE state. 

Upon initiation of the procedure, the UE shall: 
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1> If access to the cell, as specified above, is not barred: 

2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

2> start timer T300; 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 

NOTE 2: Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 



[TS 36.331, clause 5.3.3.3] 

The UE shall set the contents of RRCConnectionRequest message as follows: 

1> set the IE ue-Identity as follows: 

2> if upper layers provide an S-TMSI: 

3> set the ue-Identityio the value received from upper layers; 

2> else 

3> draw a random value and set the ue-Identity to this value; 

NOTE 1 Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell. 

1> Set the establishmentCause in accordance with the information received from upper layers; 

The UE shall submit the RRCConnectionRequest message to lower layers for transmission. 

The UE shall continue cell re-selection related measurements as well as cell re-selection evaluation. If the conditions for 
cell re-selection are fulfilled, the UE shall perform cell re-selection as specified in 5.3.3.5. 

[TS 36.331, clause 5.3.3.4] 

NOTE: Prior to this, lower layers allocate a C-RNTI. For further details see TS 36.321 [6]; 
The UE shall: 

1> establish SRBl in accordance with the received radioResourceConfiguration and as specified in 5.3.10; 

1> If stored, discard the Inter-frequency priority information and the Inter-RAT priority information provided via 
dedicated signalling using the IE idleModeMobilityControlInfo; 

1> stop timer T300; 

1> stop timer T302, if running; 

1> stop timer T303, if running; 

1> stop timer T305, if running; 

1> stop timer T320, if running; 

1> enter RRC_CONNECTED state; 

1> stop the cell re-selection procedure; 

1> set the content of RRCConnectionSetupComplete message as follows: 

2> set the selectedPLMN-Identity to the PLMN selected by upper layers [TS 23.122, TS 24.008] from the 
PLMN(s) included in the plmn-IdentityList broadcast, within SystemlnformationBlockTypel , in the cell 
where the RRC connection was established; 
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2> if upper layers provide the 'Registered MME', set the registeredMME as follows: 

3> if the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers, 
set the IE plmnldentity to the value received from upper layers; 

3> set the lEs mmegi and mmec to the value received from upper layers; 

2> set the nas-Dedicatedlnformation to include the information received from upper layers; 

2> submit the RRCConnectionSetupComplete message to lower layers for transmission, upon which the 
procedure ends. 



8.1.1.1.3 


Test description 


8.1.1.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Registered, Idle mode(state 2) according to [18]. 



8.1.1.1.3.2 



Test procedure sequence 



Table 8.1 .1 .1 .3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


The SS transmits a Paging message including 
an unmatched identity (incorrect S-TMSI). 


<- 


Paging 


- 


- 


2 


Check: Does the UE transmit an 
RRCConnectionRequest message within 5s? 


-> 


RRCConnectionRequest 


1 


F 


3 


The SS transmits a Paging message including 
a matched identity. 


<— 


Paging 


- 


- 


4 


Check: does the UE transmit an 
RRCConnectionRequest message? 


-> 


RRCConnectionRequest 


2 


P 


5 


The SS transmit an RRCConnectionSetup 
message. 


<— 


RRCConnectionSetup 


- 


- 


6 


Check: does the UE transmit an 
RRCConnectionSetupComplete message to 
confirm the successful completion of the 
connection establishment? 


-> 


RRCConnectionSetupCompiete 


2 


P 


7 


Check: does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state? 






1,2 
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8.1.1.1.3.3 



Specific message contents 

Table 8.1 .1 .1 .3.3-1 : Paging (step 1 , Table 8.1 .1 .1 .3.2-1) 



Derivation Path: 36.508 Table 4.6.1-7 | 


Information Element 


Value/remark 


Comment 


Condition 


Paging ::= SEQUENCE { 








pagingRecordList SEQUENCE (SIZE 
(1 ..maxPageRec)) QF SEQUENCE { 


1 entry 






ue-ldentity[1] CHOICE! 








s-TMSI SEQUENCE { 








mmec 


Set to the different value 
from the S-TMSI of the 
UE 






m-TMSI 


Set to the different value 
from the S-TMSI of the 
UE 






1 








1 








pagingCause[1] 


FFS 






} 








} 









Table 8.1.1.1.3.3-2: RRCConnectionRequest (step 4, Table 8.1.1.1.3.2-1) 



Derivation Path: 36.508 Table 4.6.1-15 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 








establishmentCause 


mt-Access 






} 








} 








} 









8.1 .1 .2 RRC / Paging for notification of BCCH modification in idle mode 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 

Editor's Note: The test procedure sequence should be modified because the UE can not answer to paging while 
T302 is running, so a conformant UE can not pass the test case as it is now. An alternative testing method 
could be that the SS does not answer for T300 (range is 100ms to 2s), so that the UE resumes acting on 
paging messages. 



8.1.1.2.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE receives a Paging message including an IE systemlnfoModification 
then { UE re-acquires and applies the new system information } 



8.1.1.2.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clause 5.3.2.3, 
5.2.2.3, and 5.2.2.4. 

[TS 36.331, clause 5.3.2.3] 

Upon receiving the Paging message, the UE shall: 
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1> If in RRC_IDLE, for each of the Paging records included in the Paging message: 

2> If the ue-identity included in the pagingRecordList matches one of the UE identities allocated by upper 
layers: 

3> forward the ue-Identity, the cn-Domain and the pagingCause to the upper layers. 

1> If the systemlnfoModification is included: 

2> re-acquire the required system information using the system information acquisition procedure as specified in 

5.2.2. 

[TS 36.331, clause 5.2.2.3] 

The UE shall 

1> ensure having a valid version, as defined below, of (at least) the following system information, also referred to as 
the 'required' System Information: 

2> ifinRRC_IDLE: 

3> the MasterlnformationBlock and SystemlnformationBlockTypel messages as well as 

SystemlnformationBlockTypel through SystemlnformationBlockTypeS, depending on support of the 
concerned RATs, and SystemInformationBlockType9; 



[TS 36.331, clause 5.2.2.4] 

The UE shall 

1> if the procedure is triggered by a system information change notification: 

2> start acquiring the required system information, as defined in 5.2.2.3, from the beginning of the modification 
period following the one in which the change notification was received; 



The UE may apply the received SIBs immediately i.e. the UE does not need to delay using a SIB until all SI messages 
have been received. 



8.1.1.2.3 


Test description 


8.1.1.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

- The UE is in state Registered, Idle mode state (state 2) according to [18]. 
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8.1.1.2.3.2 



Test procedure sequence 



Table 8.1.1.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a Paging message including 
matched identity. 


<- 


Paging 


- 


- 


2 


Checl<: Does the UE transmit an 
RRCConnectionRequest message? 


-> 


RRCConnectionRequest 


1 


P 


3 


The SS transmit an RRCConnectionReJect 
message. 


<- 


RRCConnectionReJect 


- 


- 


4 


The SS changes the prach-Configurationlndex 
in the system information 


- 


- 


- 


- 


5 


The SS transmits a Paging message including 
systemlnfoModification. 


<— 


Paging 


- 




6 


Wait for [X] ms for UE to receive system 
information. 


- 


- 


- 


- 


7 


The SS transmits a Paging message including 
matched identity. 


<- 


Paging 


- 




8 


Check: Does the UE transmit an 
RRCConnectionRequest message? 


-> 


RRCConnectionRequest 


1 


P 


9 


The SS transmit an RRCConnectionReJect 
message. 


<- 


RRCConnectionReJect 


- 


- 


10 


Check: the test result of CALL generic 
procedure indicates that the UE is in E-UTRA 
RRC IDLE state on Cell 1. 
NOTE: T302 (Reception of 
RRCConnectionReJect \nc\ud\r\g the IE wait 
Time) should be long enough so that this 
should be executed before the expiry of T302 






1 





8.1 .1 .2.3.3 Specific message contents 

Table 8.1.1.2.3.3-1: RRCConnectionRequest (step 2 and step 8, Table 8.1.1.2.3.2-1) 



Derivation Path: 36.508 Table 4.6.1-15 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 








establishmentCause 


mt-Access 






I 








} 








} 








Table 8.1.1.2.3.3-2: Paging (step 5, Table 8.1.1.2.3.2-1) 


Derivation Path: 36.508 Table 4.6.1-5 


Information Element 


Value/remark 


Comment 


Condition 


Paging ::= SEQUENCE { 








pagingRecordList 


Not present 






systemlnfolVlodification 


true 






} 
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Table 8.1.1.2.3.3-3: SystemlnformationBlockType2 (step 6, Table 8.1.1.2.3.2-1) 



Derivation Path: 36.508 Table 4.4.3.3-1 | 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlocl<Type2 ::= SEQUENCE { 








radioResourceConfigCommon SEQUENCE { 








prach-Configuration SEQUENCE { 








pracli-Configurationlndex 


FFS 


Set to index which 
denote subframe 
numbers different 
from the default 
one. 




} 








} 








} 









8.1 .1 .3 RRC / Paging for Connection in idle mode (multiple paging records) 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.1.1.3.1 

(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE receives a Paging message including only unmatched identities 
then { UE does not establish any RRC connection } 
} 

(2) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE receives a Paging message including any matched indentity } 
then { UE establishes an RRC connection } 



8.1.1.3.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clause 5.3.2.3, 
5.3.3.2, 5.3.3.3 and 5.3.3.4. 

[TS 36.331, clause 5.3.2.3] 

Upon receiving the Paging message, the UE shall 

1> If in RRC_1DLE, for each of the Paging records included in the Paging message: 

2> If the ue-identity included in the pagingRecordList matches one of the UE identities allocated by upper 
layers: 

3> forward the ue-Identity, the cn-Domain and the pagingCause to the upper layers. 



[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in 
RRC_1DLE state. 



Upon initiation of the procedure, the UE shall: 



1> If access to the cell, as specified above, is not barred: 
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2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

2> start timer T300; 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 

NOTE 2: Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 



[TS 36.331, clause 5.3.3.3] 

The UE shall set the contents of RRCConnectionRequest message as follows: 

1> set the IE ue-Identity as follows: 

2> if upper layers provide an S-TMSI: 

3> set the ue-Identity to the value received from upper layers; 

2> else 

3> draw a random value and set the ue-Identity to this value; 

NOTE 1 Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell. 

1> Set the establishmentCause in accordance with the information received from upper layers; 

The UE shall submit the RRCConnectionRequest message to lower layers for transmission. 

The UE shall continue cell re-selection related measurements as well as cell re-selection evaluation. If the conditions for 
cell re-selection are fulfilled, the UE shall perform cell re-selection as specified in 5.3.3.5. 

[TS 36.331, clause 5.3.3.4] 

NOTE: Prior to this, lower layers allocate a C-RNTI. For further details see TS 36.321 [6]; 
The UE shall: 

1> establish SRBl in accordance with the received radioResourceConfiguration and as specified in 5.3.10; 

1> If stored, discard the Inter-frequency priority information and the Inter-RAT priority information provided via 
dedicated signalling using the IE idleModeMobilityControlInfo; 

1> stop timer T300; 

1> stop timer T302, if running; 

1> stop timer T303, if running; 

1> stop timer T305, if running; 

1> stop timer T320, if running; 

1> enter RRC_CONNECTED state; 

1> stop the cell re-selection procedure; 

1> set the content of RRCConnectionSetupComplete message as follows: 

2> set the selectedPLMN-Identity to the PLMN selected by upper layers [TS 23.122, TS 24.008] from the 
PLMN(s) included in the plmn-IdentityList broadcast, within SystemlnformationBlockTypel , in the cell 
where the RRC connection was established; 

2> if upper layers provide the 'Registered MME', set the registeredMME as follows: 
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3> if the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers, 
set the IE plmnldentity to the value received from upper layers; 

3> set the lEs mmegi and mmec to the value received from upper layers; 

2> set the nas-Dedicatedlnformation to include the information received from upper layers; 

2> submit the RRCConnectionSetupComplete message to lower layers for transmission, upon which the 
procedure ends. 



8.1.1.3.3 


Test description 


8.1.1.3.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

- The UE is in state Registered, Idle mode (state 2) according to [18]. 



8.1.1.3.3.2 



Test procedure sequence 



Table 8.1.1.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a Paging message including 
only unmatched identities (incorrect IMSI). 


<- 


Paging 


1 


- 


2 


Check: Does the UE transmit an 
RRCConnectionRequest message for [X]s. 


-> 


RRCConnectionRequest 


1 


F 


3 


The SS transmits a Paging message including 
two unmatched identities and a matched 
identity. 


<— 


Paging 


2 




4 


Check: Does the UE transmit an 
RRCConnectionRequest message. 


~> 


RRCConnectionRequest 


2 


P 


5 


The SS transmits an RRCConnectionSetup 
message. 


<— 


RRCConnectionSetup 


- 


- 


6 


The UE transmits an 

RRCConnectionSetupComplete message to 
confirm the successful completion of the 
connection establishment. 


-> 


RRCConnectionSetupComplete 






7 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state. 






1,2 


P 
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8.1.1.3.3.3 



Specific message contents 

Table 8.1 .1 .3.3.3-1 : Paging (step 1 , Table 8.1 .1 .3.3.2-1) 



Derivation Path: 36.508 Table 4.6.1-5 


Information Element 


Value/remark 


Comment 


Condition 


Paging ::= SEQUENCE { 








pagingRecordList SEQUENCE (SIZE 
(1 ..maxPageRec)) QF SEQUENCE { 


3 entries 






ue-ldentity[1]CHQICE{ 








imsl 


Set to the different value 
from the IMSIoftheUE 






1 








pagingCause[1] 


FFS 






ue-ldentity[2] CHQICE { 








imsl 


Set to the different value 
from the IMSIoftheUE 






1 








pagingCause[2] 


FFS 






ue-ldentity[3] CHQICE { 








Imsl 


Set to the different value 
from the IMSIoftheUE 






1 








pagingCause[3] 


FFS 






} 








} 








} 









Table 8.1 .1 .3.3.3-2: Paging (step 3, Table 8.1 .1 .3.3.2-1) 



Derivation Path : 36.508 Table 4.6.1-5 


Information Element 


Value/remark 


Comment 


Condition 


Paging ::= SEQUENCE { 








pagingRecordList SEQUENCE (SIZE 
(1 ..maxPageRec)) QF SEQUENCE { 


3 entries 






ue-ldentity[1] CHQICE { 








imsl 


Set to the different value 
from the IMSIoftheUE 






1 








pagingCause[1] 


FFS 






ue-ldentity[2] CHQICE { 








imsl 


Set to the different value 
from the IMSIoftheUE 






} 








pagingCause[2] 


FFS 






ue-ldentity[3] CHQICE { 








imsl 


Set to the value of the 
IMSIoftheUE 






} 








pagingCause[3] 


FFS 






} 








} 








} 
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Table 8.1.1.3.3.3-3: RRCConnectionRequest (step 4, Table 8.1.1.3.3.2-1) 



Derivation Path: 36.508 Table 4.6.1-15 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 








establishmentCause 


mt-Access 






1 








} 








} 









8.1 .1 .4 RRC / Paging for Connection in idle mode (Shared Network environment) 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.1.1.4.1 



(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state having been registered in the TA of the current cell which has 
broadcasted a SystemlnformationBlockTypel message including multiple PLMN identities } 
ensure that { 

when { UE receives a Paging message including an IE ue-Identity set to the S-TMSI which was 
allocated to the UE at the UE registration procedure } 
then { UE establishes an RRC connection } 



8.1.1.4.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.2.3, 
5.3.3.2, 5.3.3.3 and 5.3.3.4. 

[TS 36.331, clause 5.3.2.3] 

Upon receiving the Paging message, the UE shall: 

1> If in RRC_1DLE, for each of the Paging records included in the Paging message: 

2> If the ue-identity included in the pagingRecordList matches one of the UE identities allocated by upper 
layers: 

3> forward the ue-Identity, the cn-Domain and the pagingCause to the upper layers. 



[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in 
RRC_1DLE state. 

Upon initiation of the procedure, the UE shall: 



1> If access to the cell, as specified above, is not barred: 

2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until expUcitly 
receiving a configuration; 

2> start timer T300 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 
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NOTE 2: Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information appHcable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 



[TS 36.331, clause 5.3.3.3] 

The UE shall set the contents of RRCConnectionRequest message as follows: 

1> set the IE ue-Identity as follows: 

2> if upper layers provide an S-TMSI: 

3> set the ue-Identity to the value received from upper layers; 

2> else 

3> draw a random value and set the ue-Identity to this value; 

NOTE 1 Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell. 

1> Set the establishmentCause in accordance with the information received from upper layers; 

The UE shall submit the RRCConnectionRequest message to lower layers for transmission. 

The UE shall continue cell re-selection related measurements as well as cell re-selection evaluation. If the conditions for 
cell re-selection are fulfilled, the UE shall perform cell re-selection as specified in 5.3.3.5. 

[TS 36.331, clause 5.3.3.4] 

NOTE: Prior to this, lower layers allocate a C-RNTI. For further details see TS 36.321 [6]; 
The UE shall: 

1> establish SRBl in accordance with the received radioResourceConfiguration and as specified in 5.3.10; 

1> If stored, discard the Inter-frequency priority information and the Inter-RAT priority information provided via 
dedicated signalling using the IE idleModeMobilityControlInfo; 

1> stop timer T300; 

1> stop timer T302, if running; 

1> stop timer T303, if running; 

1> stop timer T305, if running; 

1> stop timer T320, if running; 

1> enter RRC_CONNECTED state; 

1> stop the cell re-selection procedure; 

1> set the content of RRCConnectionSetupComplete message as follows: 

2> set the selectedPLMN-Identity to the PLMN selected by upper layers [TS 23.122, TS 24.008] from the 
PLMN(s) included in the plmn-IdentityList broadcast, within SystemlnformationBlockTypel , in the cell 
where the RRC connection was established; 

2> if upper layers provide the 'Registered MME', set the registeredMME as follows: 

3> if the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers, 
set the IE plmnldentity to the value received from upper layers; 

3> set the lEs mmegi and mmec to the value received from upper layers; 

2> set the nas-Dedicatedlnformation to include the information received from upper layers; 
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2> submit the RRCConnectionSetupComplete message to lower layers for transmission, upon which the 
procedure ends. 



8.1.1.4.3 


Test description 


8.1.1.4.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

- The UE is in state Registered, Idle mode (state 2) according to [18]. 



8.1.1.4.3.2 



Test procedure sequence 



Table 8.1.1.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a Paging message including 
a matched identity. 


<- 


Paging 


- 


- 


2 


Check: Does the UE transmit an 
RRCConnectionRequest message? 


-> 


RRCConnectionRequest 


1 


P 


3 


The SS transmit an RRCConnectionSetup 
message. 


<— 


RRCConnectionSetup 


- 


- 


4 


Check: Does the UE transmit an 
RRCConnectionSetupComplete message 
including an IE selectedPLMN-ldentity 
corresponding to the PLMN on which the UE 
has been registered to confirm the successful 
completion of the connection establishment? 


-> 


RRCConnectionSetupComplete 


1 


P 


5 


Check: Does the test result of CALL generic 
procedure indicates that the UE is in E-UTRA 
RRC CONNECTED state? 






1 





8.1 .1 .4.3.3 Specific message contents 

Editors note:To be updated according to agreed RRC message structure 
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Table 8.1.1.4.3.3-1 : SystemlnformationBlockTypel (all steps, Table 8.1.1.4.3.2-1) 



Derivation Path: 36.508 Table 4.4.3.2-3 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlocl<Type1 ::= SEQUENCE { 








cellAccessRelatedlnformation SEQUENCE { 








pImn-ldentityList SEQUENCE (SIZE (1 ..6)) QF 
SEQUENCE! 


2 entries 






plmn-ldentity[1] SEQUENCE { 








mcc 


FFS 






mnc 


FFS 






} 








cellReservedForOperatorUse[1] 


notReserved 






Plmn-ldentity[2] SEQUENCE { 








mcc 


FFS 






mnc 


FFS 






} 








cellReservedForOperatorUse[2] 


notReserved 






1 








1 








} 








Table 8.1.1.4.3.3-2: RRCConnectionRequest {step 2, Table 8.1.1.4.3.2-1) 


Derivation Path: 36.508 Table 4.6.1-15 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHQICE { 








rrcConnectionRequest-r8 SEQUENCE { 








establishmentCause 


mt-Access 






} 








} 








} 








Table 8.1.1.4.3.3-3: RRCConnectionSetupComplete (step 4, Table 8.1.1.4.3.2-1) 


Derivation Path: 36.508, Table 4.6.1-17 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionSetupComplete ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHQICE{ 








rrcConnectionSetupComplete-r8 SEQUENCE { 








selectedPLIVIN-ldentity 


Set to the PLMN selected 
by upper layers 






} 








1 








} 








} 









8.1 .2 RRC Connection Establishment 



8.1.2.1 



RRC Connection Establishment: Success 



8.1.2.1.1 



Test Purpose (TP) 



(1) 

with {UE in E-UTRA RRC_IDLE state} 
ensure that { 

when { UE is requested to make an outgoing call 
then { UE establishes an RRC Connection } 
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8.1 .2.1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.3.2, 
5.3.3.3 and 5.3.3.4. 

[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of a signalling connection while the UE is in 
RRCJDLE state. 

Upon initiation of the procedure, the UE shall: 



1> If access to the cell, as specified above, is not barred: 

2> apply the default physical channel configuration as specified in 9.2.4, until explicitly receiving a 
configuration; 

2> apply the default semi-persistent scheduling configuration as specified in 9.2.3, until explicitly receiving a 
configuration; 

2> apply the default transport channel configuration as specified in 9.2.2, until explicitly receiving a 
configuration; 

2> apply the CCCH configuration as specified in 9.1.1.2; 

2> start timer T300; 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3. 

NOTE 2 Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_1DLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 



[TS 36.331, clause 5.3.3.3] 

The UE shall set the contents of RRCConnectionRequest message as follows: 
1> set the IE ue-Identity as follows: 

2> if upper layers provide an S-TMSI: 

3> set the ue-Identity to the value received from upper layers; 
2> else 

3> draw a random value and set the ue-Identity to this value; 
NOTE 1 Upper layers provide the S-TMSl if the UE is registered in the TA of the current cell. 
1> Set the establishmentCause in accordance with the information received from upper layers; 
The UE shall submit the RRCConnectionRequest message to lower layers for transmission. 

[TS 36.331, clause 5.3.3.4] 

The UE shall: 

1> establish SRBl in accordance with the received radioResourceConfiguration and as specified in 5.3.10; 
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1> If stored, discard the Inter-frequency priority information and the Inter-RAT priority information provided via 
dedicated signalling using the IE idleModeMobilityControlInfo; 

1> stop timer T300; 

1> stop timer T302, if running; 

1> stop timer T303, if running; 

1> stop timer T305, if running; 

1> stop timer T320, if running; 

1> Enter RRC_CONNECTED state. 

1> stop the cell re-selection procedure; 

1> set the contents of RRCConnectionSetupComplete message as follows: 

2> set the selectedPLMN-Identity to the PLMN selected by upper layers [TS 23.122, TS 24.008] from the 

PLMNs included in the plmn-IdentityList broadcast, within SystemlnformationBlockTypel, in the cell where 
the RRC connection was established; 

2> if upper layers provide the 'Registered MME', set the registeredMME as follows: 

3> if the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers, 
set the IE plmnldentity to the value received from upper layers; 

3> set the lEs mmegi and mmec to the value received from upper layers;2> set the nas-Dedicatedlnformation 
to include the information received from upper layers; 

2> set the nas-Dedicatedlnformation to include the information received from upper layers; 

2> submit the RRCConnectionSetupComplete message to lower layers for transmission, upon which the 
procedure ends. 



8.1.2.1.3 


Test description 


8.1.2.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 
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8.1.2.1.3 



Test procedure sequence 



Table 8.1.2.1.3-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


2 


Check: does the UE transmit an 
RRCConnectionRequest message? 


--> 


RRCConnectionRequest 


1 


P 


3 


The SS transmit a RRCConnectionSetup 
message with SRB1 configuration. 


<-- 


RRCConnectionSetup 


- 


- 


4 


Check: does the UE transmit a 
RRCConnectionSetupCompleteto confirm the 
successful completion of the connection 
establishment? 


— > 


RRCConnectionSetupComplete 


1 


P 


5 


Check: does the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC CONNECTED state? 






1 





8.1.2.1.3.3 
None. 



Specific message contents 



8.1 .2.2 RRC Connection Establishment / Reject with wait time 

Editor's note: this test case description is not based on 36.331 v8.3.0. 

Editor's Note: The test procedure sequence needs updating so as to check that the UE considers the cell barred 

while T302 is running and so that a new RRCConnectionRequest message is generated after T302 expiry 
(to be done at the next RAN5 meeting) 



8.1.2.2.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state and has sent an RRCConnectionRequest message } 
ensure that { 

when { UE receives an RRCConnectionReject message including an IE waitTime set to non-zero value 
then { UE doesn't re-send RRCConnectionRequest before the waitTime is expired} 



8.1.2.2.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.3.2, 
5.3.3.3, 5.3.3.4 and 5.3.3.6. 

[TS 36.331, clause 5.3.3.2] 

Upon initiation of the procedure, the UE shall: 

1> if T302 is running and the UE is not establishing the RRC connection for emergency calls: 

2> consider access to the cell as barred; 



1> If access to the cell, as specified above, is not barred: 

2> stop acting on Paging messages; 

2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

2> start timer T300; 
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2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 

NOTE 2: Upon initiating the connection estabHshment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 

[TS 36.331, clause 5.3.3.3] 

The UE shall set the contents of RRCConnectionRequest message as follows: 

1> set the IE ue-Identity as follows: 

2> if upper layers provide an S-TMSI: 

3> set the identityType to s-TMSI; 

3> set the S-TMSI to the value received from upper layers; 

2> else 

3> set the identityType to randoniNumber; 

3> draw a random value and set the randoniNumber to this value; 

NOTE 1 Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell. 

1> Set the establishmentCause in accordance with the information received from upper layers; 

NOTE 1 Upper layers provide the S-TMSI if the UE is registered in the TA of the current cell. 

The UE shall submit the RRCConnectionRequest message to lower layers for transmission. 

[TS 36.331, clause 5.3.3.4] 

The UE shall: 

1> establish SRBl in accordance with the received radioResourceConfiguration and as specified in 5.3.10; 

NOTE 1 : The details of how the signalling radio bearer configuration is signalled are FFS, i.e. the use of a default 
RLC configuration has been agreed for SRBl. Use of default configurations for other parts of the Radio 
resource configuration is not precluded. 

1> If stored, discard the Inter-frequency priority information and the Inter-RAT priority information provided via 
dedicated signalling using the IE idleModeMobilityControlInfo; 

1> stop timer T300; 

1> stop timer T302, if running; 

1> stop timer T303, if running; 

1> stop timer T305, if running; 

1> stop timer T320, if running; 

1> enter RRC_CONNECTED state; 

1> stop the cell re-selection procedure; 

1> set the content of RRCConnectionSetupComplete message as follows: 

2> set the selectedPLMN-Identity to the PLMN selected by upper layers [TS 23.122, TS 24.008] from the 
PLMNs included in the plmn-IdentityList broadcast within SystemlnformationBlockTypel , in the cell where 
the RRC connection was established (it is FFS when the UE shall include this IE, possibly on whether the UE 
has a vaHd S-TMSI); 
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2> if upper layers provide the 'Registered MME', set the registeredMME as follows: 

3> if the PLMN identity of the 'Registered MME' is different from the PLMN selected by the upper layers, 
set the IE plmnldentity to the value received from upper layers; 

3> set the lEs mmegi and mmec to the value received from upper layers; 

2> set the nas-Dedicatedlnformation to include the information received from upper layers; 

2> submit the RRCConnectionSetupComplete message to lower layers for transmission, upon which the 
procedure ends. 

[TS 36.331, clause 5.3.3.6] 

The UE shall: 

1> stop timer T300; 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> resume acting on Paging messages; 

1> start timer T302, with a timer value set according to the value of the waitTime; 



8.1.2.2.3 




8.1.2.2.3.1 




System SirriL 


lator 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 



Preamble: 

- The UE is in state Registered, Idle mode (state 2) according to [18]. 



8.1.2.2.3.2 



Test procedure sequence 



Table 8.1.2.2.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


Message 


1 


IVIake UE attempt an outgoing call 


- 


- 


- 


- 


2 


Check: UE transmits an 
RRCConnectionRequest message. 


— > 


RRCConnectionRequest 


- 


- 


3 


SS responds with RRCConnectionReject 
message with IE iva/f 7/me set to 10s. 


<— 


RRCConnectionReject 


- 


- 




EXCEPTION: the behaviour in table 

8.1 .2.6.3.2-2 runs in parallel with step 4 below. 










4 


Make UE attempt an outgoing call. 










8 


Check: the test results of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC IDLE state. 






1 


P 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



227 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



Table 8.1.2.2.3.2-2: Parallel behaviour 



Procedure 



St 



Check: does the UE transmit an 
RRCConnectionRequest message within 16s ? 



U-S 



imessage Sequence 



miessage 



TP 



Verdict 



RRCConnectionRequest 



8.1.2.2.3.3 
None. 

8.1.2.3 



Specific message contents 



RRC Connection Establishment in RRC_IDLE state: return to idle state after 
T300 timeout 



Editor's note: this test case description is not based on 36.331 v8.3.0. 
8.1.2.3.1 Test Purpose (TP) 

(1) 

with {UE in E-UTRA RRC_IDLE state having sent an RRCConnectionRequest message} 
ensure that { 

when { the SS does not answer to the UE during T300} 
then {UE goes to RRC_IDLE} 
} 

8.1.2.3.1 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.3.6. 

[TS 36.331, clause 5.3.3.6] 

The UE shall: 

1> if timer T300 expires or 

1> if cell reselection occurs during RRC connection establishment: 

2> stop timer T300, if running; 

2> stop timer T302, if running; 

2> stop timer T303, if running; 

2> stop timer T305, if running; 

2> reset MAC and re-establish RLC for all RBs that are established; 

2> resume acting on Paging messages; 

2> inform upper layers about the failure to establish the RRC connection, upon which the procedure ends. 

8.1.2.3.3 Test description 

8.1.2.3.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

UE: 
None. 
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Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 



8.1.2.3.3.2 



Test procedure sequence 



Table 8.1.2.3.3-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


Make UE attempt an outgoing call 


- 


- 


- 


- 


2 


UE transmits an RRCConnectionRequest 
message. 


— > 


RRCConnectionRequest 


- 


- 


3 


The SS waits for T300. 

Note: the UE may transmit one or more 
RRCConnectionRequest messages but the SS 
does not answer to these messages. 


— > 


RRCConnectionRequest 






4 


Check: the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC IDLE state. 






1 


P 



8.1.2.3.3.3 
FFS 



Specific message contents 



8.1 .2.5 RRC Connection Establishment: 0% access probability for MO calls, no 

restriction for MO signalling. 



Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.1.2.5.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state having received SystemInformationBlockType2 indicating 0% access 
probability for MO calls } 
ensure that { 

when { UE is requested to make an outgoing call } 

then { UE does not transmit any RRCConnectionRequest message } 
} 

(2) 

with { UE in E-UTRA RRC_IDLE state } 
ensure that { 

when { UE reselects a new cell which belongs to different TA and broadcasts 
SystemInformationBlockType2 indicating no restriction for MO signalling } 
then { UE transmits an RRCConnectionRequest message } 
} 

(3) 

with { UE in E-UTRA RRC_IDLE state having received SystemInformationBlockType2 with no restriction } 
ensure that { 

when { UE is requested to make an outgoing call } 

then { UE transmits an RRCConnectionRequest message } 
} 

8.1.2.5.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.3.2. 

[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in 
RRCJDLE state. 
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Upon initiation of the procedure, the UE shall: 

1> If the UE is establishing the RRC connection for mobile terminating calls: 

1> else if the UE is establishing the RRC connection for emergency calls: 

1> else if the UE is establishing the RRC connection for mobile originating calls: 

2> if timer T302 or T303 is running: 

3> consider access to the cell as barred; 

2> else if SystemInformationBlockType2 includes the accessBarringlnformation and the 
accessBarringForOriginatingCalls is present: 

3> if the UE has one or more Access Classes, as stored on the USIM, with a value in the range 11. .15, which 
is valid for the UE to use according to TS 22.01 1 [10] and TS 23. 122 [11], and 

NOTE 1: ACs 12, 13, 14 are only valid for use in the home country and ACs 11, 15 are only valid for use in the 
HPLMN/ EHPLMN. 

3> for at least one of these Access Classes the accessClassBarring in the accessClassBarringList contained 
in accessBarringForOriginatingCalls is set to FALSE: 

4> consider access to the cell as not barred; 

3> else: 

4> draw a random number 'rand' uniformly distributed in the range: < rand < 1 ; 

4> if 'rand' is lower than the value indicated by accessProbability Factor included in 
accessBarringForOriginatingCalls: 

5> consider access to the cell as not barred; 

4> else: 

5> consider access to the cell as barred; 

2> else: 

3> consider access to the cell as not barred; 

1> else (the UE is establishing the RRC connection for mobile originating signalling): 

2> if timer T302 or T305 is running: 

3> consider access to the cell as barred; 

2> else if SystemInformationBlockType2 includes the accessBarringlnformation and the 
accessBarringForSignalling is present: 

3> if the UE has one or more Access Classes, as stored on the USIM, with a value in the range 1 1..15, which 
is valid for the UE to use according to TS 22.01 1 [10] and TS 23. 122 [11], and 

3> for at least one of these Access Classes the accessClassBarring in the accessClassBarringList contained 
in accessBarringForSignalling is set to FALSE: 

4> consider access to the cell as not barred; 

3> else: 

4> draw a random number 'rand' uniformly distributed in the range: < rand < 1 ; 
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4> if 'rand' is lower than the value indicated by accessProbabilityFactor included in 
accessBarringForSignalling: 

5> consider access to the cell as not barred; 

4> else: 

5> consider access to the cell as barred; 

2> else: 

3> consider access to the cell as not barred; 

1> If access to the cell, as specified above, is not barred: 

2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

2> start timer T300; 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 

NOTE 2: Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 



8.1.2.5.3 
8.1.2.5.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 and Cell 2 

UE: 
None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) on Cell 1 according to [18]. 



8.1.2.5.3.2 



Test procedure sequence 



Table 8.1.2.5.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.1.2.5.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be assigned 
values to satisfy SrxlevCell 1 > 
SrxlevCell 2 such that camping on 
Cell 1 is guaranteed 


Tl 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be assigned 
values to satisfy RCell 1 < RCell 2. 
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Table 8.1.2.5.3.2-2: Main Behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


IVIal<e the UE initiate an outgoing call. 


- 


- 


- 


- 


2 


Check: Does the UE transmit an 
RRCConnectionRequest message within 5s? 


— > 


RRCConnectionRequest 


1 


F 


3 


The SS changes Cell 1 and Cell 2 level 
according to the row "11 " in table 8.1 .2.5.3.2-1 . 


- 


- 


- 


- 


4 


Check: Does the UE transmit an 
RRCConnectionRequest message on Cell 2? 


— > 


RRCConnectionRequest 


2 


P 


5 


The SS transmits an RRCConnectionSetup 
message. 


<— 


RRCConnectionSetup 


- 


- 


6 


The UE transmits an 
RRCConnectionSetupComplete message. 


— > 


RRCConnectionSetupComplete 


- 


- 


7 


The SS transmits a SecurityModeCommand 
message to activate AS security. 


<— 


SecurityModeCommand 


- 


- 


8 


The UE transmits a SecuritylVlodeComplete 
message and establishes the initial security 
configuration. 


— > 


SecurityModeComplete 






9 


The SS transmits an 
RRCConnectionReconfiguration message. 


<— 


RRCConnectionReconfiguration 


- 


- 


10 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






11 


The SS transmits an RRCConnectionRelease 
message to release RRC connection and 
move to E-UTRA RRC IDLE state. 


<— 


RRCConnectionRelease 






12 


Wait for 5 s for the UE to enter E-UTRA 
RRC IDLE state. 


- 


- 


- 


- 


13 


The SS transmits a Paging message including 
systemlnfoModification. 


<— 


Paging 


- 


- 


14 


The SS changes 

SystemlnformationBlockType2 parameters to 
default parameters defined in [18]. 










15 


Wait for 1 5 s for the UE to receive system 
information. 


- 


- 


- 


- 


16 


IVIake the UE initiate an outgoing call. 


- 


- 


- 


- 


17 


Check: Does the UE transmit an 
RRCConnectionRequest message. The UE 
starts T300? (Note 1) 


— > 


RRCConnectionRequest 


3 


P 


18 


Wait for 5 s to ensure that T300 expires. 


- 


- 


- 


- 


19 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC IDLE state on Cell 2. 






1,2, 
3 




Note 1 : It is not required to cliecl< that the T300 is started. 



8.1 .2.5.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.1.2.5.3.3-1 : SystemlnformationBlockTypel for Cell 1 and Cell 2 (preamble and all steps, Table 

8.1.2.5.3.2-2) 



Derivation Path: 36.508, Table 4.4.3.2-3 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlocl<Type1 ::= SEQUENCE { 








cellAccessRelatedlnformation SEQUENCE { 








trackingAreaCode 


FFS 




CelH 




FFS 




Cell 2 


cell Identity 


FFS 




Cell 1 




FFS 




Cell 2 


} 








} 









Condition 


Explanation 


Cell 1 


This condition applies to system information transmitted on Cell 1 . 


Cell 2 


This condition applies to system information transmitted on Cell 2. 



Table 8.1.2.5.3.3-2: SystemlnformationBlockType2 for Cell 1 and Cell 2 (preamble and all steps, Table 

8.1.2.5.3.2-2) 



Derivation Path: 36.508, Table 4.4.3.3-1 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 








accessBarringlnformation SEQUENCE { 








accessBarringForEmergencyCalls 


FALSE 






accessBarringForSignalling 


Not present 






accessBarringForQriginatingCalls SEQUENCE { 








accessProbabilityFactor 


pOO 






accessBarringTime 


s4 






accessClassBarringList SEQUENCE (SIZE 
(maxAC)) OF SEQUENCE { 


5 entries 






accessClassBarring[1 ] 


FALSE 






accessClassBarring[2] 


FALSE 






accessClassBarring[3] 


FALSE 






accessClassBarring[4] 


FALSE 






accessClassBarring[5] 


FALSE 






} 








1 








} 








} 








Table 8.1.2.5.3.3-3: RRCConnectionRequest (step 4, Table 8.1.2.5.3.2-2) 


Derivation Path: 36.508, Table 4.6.1-15 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 


mo-Signalling 






establishmentCause 








} 








} 








} 
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Table 8.1.2.5.3.3-4: RRCConnectionReconfiguration (step 9, Table 8.1.2.5.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6, condition DRB(1,0) | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








nas-Dedicatedlnformation 


FFS (TRACKING AREA 
UPDATE ACCEPT) 






} 








} 








} 








1 









Table 8.1.2.5.3.3-5: Paging (step 13, Table 8.1.2.5.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-5 | 


Information Element 


Value/remark 


Comment 


Condition 


Paging ::= SEQUENCE { 








pagingRecordList 


Not present 






systemlnfoModification 


true 






} 









Table 8.1.2.5.3.3-6: RRCConnectionRequest (step 17, Table 8.1.2.5.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-15 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 


mo-Data 






establishmentCause 








} 








} 








} 









8.1 .2.7 RRC Connection Establishment: 0% access probability for AC 0..9, AC 1 is 

barred, AC 11 ..1 5 are not barred, access for UE with the access class is in 
the range 1 1 ..1 5 is allowed. 



Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.1.2.7.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_IDLE state having an Access Class with a value in the range 11.. 15 and 
having received SystemInformationBlockType2 indicating 0% access probability for AC 0..9 for both MO 
call and MO signalling, access restriction for AC 10 and no restriction for AC 11. .15 for both MO 
call and MO signalling } 
ensure that { 

when { UE is requested to make an outgoing call } 

then { UE transmits an RRCConnectionRequest message } 
} 

(2) 

with { UE in E-UTRA RRC_IDLE state having an Access Class with a value in the range 11.. 15 } 
ensure that { 

when { UE reselects a new cell which belongs to different TA and broadcasts 
SystemInformationBlockType2 indicating 0% access probability for AC 0. .9 for both MO call and MO 
signalling, access restriction for AC 10 and no restriction for AC 11. .15 for both MO call and MO 
signalling } 
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then { UE transmits an RRCConnectionRequest message } 
} 

(3) 

with { UE in E-UTRA RRC_IDLE state having an Access Class with a value in the range 11. .15 and 
having received SystemInformationBlockType2 indicating 0% access probability for AC 0..9 for both MO 
call and MO signalling, access restriction for AC 10 and no restriction for the Access Class 11. .15 
for both MO call and MO signalling } 
ensure that { 

when { UE receives Paging message including a matched identity } 
then { UE transmits an RRCConnectionRequest message } 
} 

(4) 

with { UE in E-UTRA RRC_IDLE state having received SystemInformationBlockType2 with no restriction } 
ensure that { 

when { UE is requested to make an outgoing call } 

then { UE transmits an RRCConnectionRequest message } 
} 

8.1.2.7.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.3.2. 

[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in 
RRCJDLE state. 

Upon initiation of the procedure, the UE shall: 

1> If the UE is establishing the RRC connection for mobile terminating calls: 

2> if timer T302 is running: 

2> else: 

3> consider access to the cell as not barred; 
1> else if the UE is establishing the RRC connection for emergency calls: 

1> else if the UE is establishing the RRC connection for mobile originating calls: 
2> if timer T302 or T303 is running: 



2> else if SystemInformationBlockType2 includes the accessBarringlnformation and the 
accessBarringForOriginatingCalls is present: 

3> if the UE has one or more Access Classes, as stored on the USIM, with a value in the range 11. .15, which 
is valid for the UE to use according to TS 22.01 1 [10] and TS 23. 122 [11], and 

NOTE 1: ACs 12, 13, 14 are only valid for use in the home country and ACs 11, 15 are only valid for use in the 
HPLMN/ EHPLMN. 

3> for at least one of these Access Classes the accessClassBarring in the accessClassBarringList contained 
in accessBarringForOriginatingCalls is set to FALSE: 

4> consider access to the cell as not barred; 

3> else: 
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1> else (the UE is establishing the RRC connection for mobile originating signalling): 
2> if timer T302 or T305 is running: 



2> else if SystemInformationBlockType2 includes the accessBarringlnformation and the 
accessBarringForSignalling is present: 

3> if the UEhas one or more Access Classes, as stored on the USIM, with a value in the range 11.. 15, which 
is valid for the UE to use according to TS 22.01 1 [10] and TS 23. 122 [11], and 

3> for at least one of these Access Classes the accessClassBarring in the accessClassBarringList contained 
in accessBarringForSignalling is set to FALSE: 

4> consider access to the cell as not barred; 

3> else: 



1> If access to the cell, as specified above, is not barred: 

2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

2> start timer T300; 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 

NOTE 2: Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 



8.1.2.7.3 Test description 

8.1.2.7.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 and Cell 2 

- Cell 1 belongs to TAI-1(MCC1/MNC1/TAC1) and Cell 2 belongs to TA1-2(MCC1/MNC1/TAC2). 

UE: 

USIM with one or more Access Classes of a value in the range 1 1.. 15 is inserted 

Preamble: 

The UE is in state Registered, Idle mode (state 2) on Cell 1 according to [18]. 

8.1 .2.7.3.2 Test procedure sequence 

Table 8.1.2.7.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 
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Table 8.1.2.7.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Celll 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be assigned 
values to satisfy SrxlevCell 1 > 
SrxlevCell 2 such that camping on 
Cell 1 is guaranteed 


T1 


Ro 


dBm 


P11 (FFS) 


PI 2 (FFS) 


P1 1 and PI 2 shall be assigned 
values to satisfy RCell 1 < RCell 2. 



Table 8.1.2.7.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


IVIake the UE initiate an outgoing call. 


- 


- 


- 


- 


2 


Check: Does the UE transmit an 
RRCConnectionRequest message. The UE 
starts T300.(Note 1) 


— > 


RRCConnectionRequest 


1 


P 


3 


Wait for 5 s to ensure that T300 expires. 


- 


- 


- 


- 


4 


The SS changes Cell 1 and Cell 2 level 
according to the row "T1 " in table 8.1 .2.7.3.2-1 . 


- 


- 


- 


- 


5 


Check: Does the UE transmit an 
RRCConnectionRequest message on Cell 2. 


— > 


RRCConnectionRequest 


2 


P 


6 


The SS transmits an RRCConnectionSetup 
message. 


<— 


RRCConnectionSetup 


- 


- 


7 


The UE transmits an 
RRCConnectionSetupComplete message. 


-> 


RRCConnectionSetupComplete 


- 


- 


8 


The SS transmits an 
RRCConnectionReconfiguration message. 


<— 


RRCConnectionReconfiguration 


- 


- 


9 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






10 


The UE transmits an ULInformationTransfer 
message. 


-> 


UL Information Transfer 


- 


- 


11 


The SS transmits an RRCConnectionRelease 
message to release RRC connection and 
move to E-UTRA RRC IDLE state. 


<— 


RRCConnectionRelease 






12 


Wait for 5 s for the UE to enter E-UTRA 
RRC IDLE state. 


- 


- 


- 


- 


13 


The SS transmits a Paging message including 
a matched identity. 


<— 


Paging 


- 


- 


14 


Check: Does the UE transmit an 
RRCConnectionRequest message. The UE 
starts T300.(Note 1) 


— > 


RRCConnectionRequest 


3 


P 


15 


Wait for 5 s to ensure that T300 expires. 


- 


- 


- 


- 


16 


The SS transmits a Paging message including 
systemlnfoModification. 


<— 


Paging 


- 


- 


17 


The SS changes 

SystemlnformationBlockType2 parameters to 
default parameters defined in [18]. 










18 


Wait for 1 5 s for the UE to receive system 
information. 


- 


- 


- 


- 


19 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


20 


Check: Does the UE transmit an 
RRCConnectionRequest message. The UE 
starts T300.(Note 1) 


— > 


RRCConnectionRequest 


4 


P 


21 


Wait for 5 s to ensure that T300 expires. 


- 


- 


- 


- 


22 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC IDLE state on Cell 2. 






1,2, 
3,4 





8.1 .2.7.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.1.2.7.3.3-1 : SystemlnformationBlockTypel for Cell 1 and Cell 2 (preamble and all steps before 

step 18, Table 8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.4.3.2-3 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlocl<Type1 ::= SEQUENCE { 








cellAccessRelatedlnformation SEQUENCE { 








trackingAreaCode 


TAC1 




CelH 




TAC2 




Cell 2 


cell Identity 


FFS 




Cell 1 




FFS 




Cell 2 


} 








} 









Condition 


Explanation 


Cell 1 


This condition applies to system information transmitted on Cell 1 . 


Cell 2 


This condition applies to system information transmitted on Cell 2. 



Table 8.1.2.7.3.3-2: SystemlnformationBlockType2 ior Cell 1 and Cell 2 (preamble and all steps, Table 

8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.4.3.3-1 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 








accessBarringlnformation SEQUENCE { 








accessBarringForEmergencyCalls 


TRUE 






accessBarringForSignalling SEQUENCE { 








accessProbabilityFactor 


pOO 






accessBarringTime 


s4 






accessClassBarringList SEQUENCE (SIZE 
(maxAC)) OF SEQUENCE { 


5 entries 






accessClassBarring[1 ] 


FALSE 






accessClassBarring[2] 


FALSE 






accessClassBarring[3] 


FALSE 






accessClassBarring[4] 


FALSE 






accessClassBarring[5] 


FALSE 






} 








} 








accessBarringForQrigJnatingCalls SEQUENCE { 








accessProbabilityFactor 


pOO 






accessBarringTime 


s4 






accessClassBarringList SEQUENCE (SIZE 
(maxAC)) OF SEQUENCE { 


5 entries 






accessClassBarring[1 ] 


FALSE 






accessClassBarring[2] 


FALSE 






accessClassBarring[3] 


FALSE 






accessClassBarring[4] 


FALSE 






accessClassBarring[5] 


FALSE 






1 








} 








} 








} 
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Table 8.1.2.7.3.3-3: RRCConnectionRequest (step 2 and 22, Table 8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-16 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 








establishmentCause 


mo- Data 






1 








} 








} 









Table 8.1.2.7.3.3-4: RRCConnectionRequest (step 5, Table 8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-16 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectlonRequest-r8 SEQUENCE { 








establishmentCause 


mo-Signalling 






} 








} 








} 









Table 8.1.2.7.3.3-5: RRCConnectionReconfiguration (step 8, Table 8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-8, condition DRB(1,0) 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEQUENCE { 








nas- Dedicated 1 nformation 


TRACKING AREA 
UPDATE ACCEPT 






} 








1 








} 








} 









Table 8.1.2.7.3.3-6: ULInformationTransfer (step 10, Table 8.1.2.7.3.2-2) 



Derivation path: 36.508 table 4.6.1-26 


Information Element 


Value/Remark 


Comment 


Condition 


ULInformationTransfer ::= SEQUENCE { 
criticalExtensions CHOICE { 
c1 CHOICE! 
ullnformationTransfer-rS SEQUENCE { 
InformationType CHOICE { 
nas3GPP 

} 
} 
} 
} 
1 




TRACKING AREA 

UPDATE 

COMPLETE 
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Table 8.1.2.7.3.3-7: RRCConnectionRequest (step 14, Table 8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-16 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 SEQUENCE { 








establishmentCause 


mt-Access 






1 








} 








} 









Table 8.1.2.7.3.3-7: Paging (step 16, Table 8.1.2.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-7 | 


Information Element 


Value/remark 


Comment 


Condition 


Paging ::= SEQUENCE { 








pagingRecordLlst 


Not present 






systemlnfolVlodification 


true 






} 









8.1 .2.8 RRC Connection Establishment: range of access baring time 

Editor's Note: This section is based on 36.331 v8.2.0 i.e. after RAN#40 + R2-083795. 



8.1.2.8.1 



(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state with T303 running } 
ensure that { 

when { UE is requested to make an outgoing call } 

then { UE does not transmit any RRCConnectionRequest message } 

} 

(2) 

with { UE in E-UTRA RRC_IDLE state having received SystemInformationBlockType2 with no restriction 
ensure that { 

when { UE is requested to make an outgoing call } 

then { UE transmits an RRCConnectionRequest message } 
} 

8.1.2.8.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.3.2. 

[TS 36.331, clause 5.3.3.2] 

The UE initiates the procedure when upper layers request establishment of an RRC connection while the UE is in 
RRC_1DLE state. 

Upon initiation of the procedure, the UE shall: 

1> if T302 is running and the UE is not establishing the RRC connection for emergency calls: 

2> consider access to the cell as barred; 
1> else if SystemInformationBlockType2 includes the accessBarringlnformation: 

2> if the UE is establishing the RRC connection for emergency calls: 

2> else if the UE is establishing the RRC connection for mobile terminating access: 
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2> else if the UE is establishing the RRC connection for mobile originating signalling: 

2> else: 

3> if the accessBarringlnformation includes accessBarringForOriginatingCaUs: 

4> if the UE has one or more Access Classes, as stored on the USIM, with a value in the range 11. .15, 
which is vaHd for the UE to use according to TS 22.01 1 [10] and TS 23.122 [11], and 

4> for at least one of these Access Classes the accessClassBarring in the accessClassBarringList 
contained in accessBarringForOriginatingCalls is set to FALSE : 

5> consider access to the cell as not barred; 

4> else: 

5> if T303 is running: 

6> consider access to the cell as barred; 

5> else: 

6> draw a random number 'rand' uniformly distributed in the range: < rand < 1 

6> if 'rand' is lower than the value indicated by the accessProbability Factor included in 
accessBarringForOriginatingCalls: 

7> consider access to the cell as not barred; 

6> else: 

7> consider access to the cell as barred; 

3> else: 

4> consider access to the cell as not barred; 

1> else: 

2> consider access to the cell as not barred; 

1> If access to the cell, as specified above, is not barred: 

2> stop acting on Paging messages; 

2> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

2> start timer T300; 

2> initiate transmission of the RRCConnectionRequest message in accordance with 5.3.3.3; 

NOTE 2: Upon initiating the connection establishment procedure, the UE is not required to ensure it maintains up 
to date system information applicable only for UEs in RRC_IDLE state. However, the UE needs to 
perform system information acquisition upon re-selection. 

1> else: 

2> if the UE is not establishing the RRC connection for emergency calls; and 

2> if T302 is not running: 

3> if the UE is establishing the RRC connection for mobile originating signalling: 
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4> if T305 is not running: 

5> draw a random number 'rand' that is uniformly distributed in the range < rand < 1; 

5> start timer T305 with a timer value calculated as follows, using the accessBarringTime included in 
accessBarringForSignalling: 

T305= (0.7 + 0.6 * rand) * accessBarringTime 

3> else: 

4> if T303 is not running: 

5> draw a random number 'rand' that is uniformly distributed in the range < rand < 1; 

5> start timer T303 with a timer value calculated as follows, using the accessBarringTime included in 
accessBarringForOriginatingCalls: 

T303= (0.7+ 0.6 * rand) * accessBarringTime 

2> inform upper layers about the failure to establish the RRC connection, upon which the procedure ends. 



8.1.2.8.3 


Test description 


8.1.2.8.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in Registered, Idle mode state (state 2) according to [18]. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



242 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



8.1.2.8.3.2 



Test procedure sequence 



Table 8.1.2.8.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a Paging message including 
systemlnfoModification. 


<-- 


Paging 


- 


- 


2 


The SS changes 

SystemlnformationBlockType2 parameters to 
50% access probability for MO calls. 










3 


Wait for [15] s for the UE to receive system 
information. 


- 


- 


- 


- 


4 


The SS initializes an internal flag F to TRUE. 


- 


- 


- 


- 


- 


EXCEPTION: Step 5 shall be repeated while 
the flag F is TRUE. 


- 


- 


- 


- 


5 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


5a 


IF the UE does not transmit any 
RRCConnectionRequest message (The UE 
starts T303) (Note 2) THEN the SS sets the 
flag F to FALSE. 






1 




5b 


ELSE IF the UE transmits an 
RRCConnectionRequest message (The UE 
starts T300) (Note 1 ) THEN wait for [5] s to 
ensure that T300 expires. 


— > 


RRCConnectionRequest 






- 


EXCEPTION: Step 6 to 7 shall be repeated 35 
times (every 10s). 


- 


- 


- 


- 


6 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


7 


Check: Does the UE transmit an 
RRCConnectionRequest message within 5s? 


— > 


RRCConnectionRequest 


1 


F 


8 


Wait for 20 s to ensure that T303 expires. 


- 


- 


- 


- 


9 


The SS transmits a Paging message including 
systemlnfoModification. 


<— 


Paging 


- 


- 


10 


The SS changes 

SystemlnformationBlockType2 parameters to 
those used before the step 1 . 










11 


Wait for [15] s for the UE to receive system 
information. 


- 


- 


- 


- 


12 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


13 


Check: Does the UE transmit an 
RRCConnectionRequest message. The UE 
starts T300.(Note1)? 


— > 


RRCConnectionRequest 


2 


P 


14 


Wait for [5] s to ensure that T300 expires. 


- 


- 


- 


- 


15 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC IDLE state? 






1,2 





8.1 .2.8.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.1 .2.8.3.3-1: Paging (step 1, Table 8.1.2.8.3.2-1) 

FFS 
Table 8.1.2.8.3.3-2: SystemlnformationBlockType2 (step 2, Table 8.1.2.8.3.2-1) 

FFS 
Table 8.1.2.8.3.3-3: RRCConnectionRequest (step 5b, Table 8.1.2.8.3.2-1) 

FFS 
Table 8.1.2.8.3.3-4: Paging (step 9, Table 8.1.2.8.3.2-1) 

FFS 
Table 8.1.2.8.3.3-5: RRCConnectionRequest (step 13, Table 8.1.2.8.3.2-1) 

FFS 

8.1 .2.1 RRC Connection Establishment during Cell reselection: Failure 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 

Editor's Note: There are some concerns on the feasibility of this test case, see editor's notes at the end of section 
8.1.2.10.3.2. 

8.1.2.10.1 Test Purpose (IP) 
(1) 

with { UE in E-UTRA RRC_IDLE state having transmitted an RRCConnectionRequest message } 
ensure that { 

when { UE recognises that the current cell conditions change and new cell meets the cell re- 
selection criteria } 

then { UE selects the new cell and stops establishment of the RRC connection } 
} 

8.1.2.10.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.3.5. 
[TS 36.331, clause 5.3.3.5] 
The UE shall: 

1> If cell reselection occm^s while T300 is running: 

2> stop timer T300; 

2> stop timer T302, if running; 

2> stop timer T303, if running; 

2> stop timer T305, if running; 

2> reset MAC; 

2> inform upper layers about the failure to establish the RRC connection, upon which the procedure ends. 
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8.1.2.10.3 
8.1.2.10.3.1 



Test description 
Pre-test conditions 



System Simulator: 

2 cells on same E-UTRA frequency (FDD for both or TDD for both): 
Cell 1 : serving cell 
Cell 2: intra-frequency cell 

UE: 
None. 

Preamble: 

UE is brought to state Registered, Idle mode (state 2) on Cell 1 according to [18]. 



8.1.2.10.3.2 



Test procedure sequence 



Table 8. 1 .2. 10.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.1.2.10.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


Shall be assigned values to 
satisfy SrxlevCell 1 > 
SrxlevCell 2 such that camping 
on Cell 1 is guaranteed 


Tl 


Ro 


clBm 


P11 (FFS) 


P02 (FFS) 


Power P11 shall be assigned 
values to satisfy RCell 1 < 
RCell 2. 



Table 8.1.2.10.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


IVIake UE initiate an outgoing call. 


- 


- 


- 


- 


2 


Check: Does the UE transmit an 
RRCConnectionRequest on Cell 1? 


-> 


RRCConnectionRequest 


1 


P 


3 


The SS changes Cell 1 and Cell 2 level 
according to the row "Tl " in table 8.1 .2.1 0.3.2- 
1. 










4 


Wait for [x]s to ensure that the UE camps on 
Cell 2. 


- 


- 


1 


P 


5 


Check: Does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC IDLE state on Cell2.(FFS)? 






1 





Editor's note: This test case is not really checking the test purpose: the maximum value of T300 is 2, so if 
waiting for more than 2s as now specified in step 4, normal cell selection after T300 expiry occurs. 

Editor's note: It may be possible to check the purpose of this test case using T300=2s and Treselection= 0, 

assuming the SS can change the poser of Cell 1 and Cell 2 within 0.5s after RRCConnectionRequest is 
received in step 2, Is could be enough for cell reselection (needs checking with 36.133), then paging 
could be sent within 1.5s- 1.6s, so that the RRCConnectionRequest on Cell 2 comes before T300 expiry. If 
any of the above assumption is not true, this test case may not be feasible. 
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8.1.2.10.3.3 Specific message contents 

Table 8.1.2.10.3.3-1 : SystemlnformationBlockType2 for Cell 1 (pre-test conditions) 



Derivation Path: 36.508 Table 4.4.3.3-1 | 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlocl<Type2 ::= SEQUENCE { 








ue-TimersAndConstants SEQUENCE { 








t300 


ms2000 






} 
















} 









Table 8.1.2.10.3.3-2: SystemlnformationBlockType3 for Cell 1 (pre-test conditions) 



Derivation Path: 36.508 Table 4.4.3.3-2 | 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockTypeS ::= SEQUENCE { 








cellReselectioninfoCommon SEQUENCE { 








t-ReselectionEUTRAN 









} 
















} 









Table 8.1.2.10.3.3-3 RRCConnectionRequest (step 2, Table 8.1.2.10.3.2-1) 



Derivation Path: 36.508 Table 4.6.1-15 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRequest ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRequest-r8 = SEQUENCE { 








establishmentCause 


mo- Data 






1 








} 








} 









8.1 .3 RRC Connection Release 

8.1 .3.1 RRC Connection Release: Success 

Editor's note: this test case description is not based on 36.331 v8.3.0. 

8.1.3.1.1 Test Purpose (TP) 
(1) 

with { UE in RRC_CONNECTED state} 
ensure that { 

when { UE receives an RRCConnectionRelease message } 
then { UE releases the signalling connection, the established EPS bearer and all radio resources 
and enters in RRC_IDLE state } 
} 

8.1 .3.1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.8.3. 
[TS 36.331, clause 5.3.8.3] 
The UE shall: 
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1> delay the following actions defined in this sub-clause 60ms from the moment the RRCConnectionRelease 
message was received or optionally when lower layers indicate that the receipt of the RRCConnectionRelease 
message has been successfully acknowledged, whichever is earlier; 

1> indicate the release of the RRC connection to upper layers; 

1> release all radio resources; 



1> enter RRCJDLE. 



8.1.3.1.3 


Test description 


8.1.3.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.1.3.1.3.2 



Test procedure sequence 



Table 8.1.3.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


SS transmits a RRCConnectionRelease 
message to release the RRC connection. 


<- 


RRCConnectionRelease 


- 


- 


2 


SS waits for [x1] ms + 5s. 


- 


- 


- 


- 


3 


Check: the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC IDLE state. 






1 


P 



Specific message content 

RRC Connection Release: UE stays on same cell 
Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an RRCConnectionRelease message and a cell with higher Srxlev than serving cell 
exist } 

then { UE enters E-UTRA RRC_IDLE state on the last cell for which UE was in E-UTRA RRC_CONNECTED 
state } 



8.1.3.1.3.3 


None. 


8.1.3.3 


8.1.3.3.1 


(1) 
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8.1.3.3.1 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.8.3 
and 3GPP TS 36.304 clauses 5.2.4.6 and 5.2.7. 

[TS 36.331, clause 5.3.8.3] 

The UE shall: 

1> delay the following actions defined in this sub-clause 60ms from the moment the RRCConnectionRelease 
message was received or optionally when lower layers indicate that the receipt of the RRCConnectionRelease 
message has been successfully acknowledged, whichever is earlier; 

1> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 



[TS 36.304, clause 5.2.4.6] 

In all cases, the UE shall reselect the new cell, only if the following conditions are met: 

the new cell is better ranked than the serving cell during a time interval Treselections 

[TS 36.304, clause 5.2.7] 

On transition from RRC_CONNECTED to RRC_1DLE, a UE shall attempt to camp on the last cell for which it was in 
RRC_CONNECTED or any cell on a frequency or frequency of RAT by RRC in the state transition message. 



8.1.3.3.3 
8.1.3.3.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 and Cell 2 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.1.3.3.3.2 



Test procedure sequence 



Table 8.1.3.3.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.1.3.3.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


Shall be assigned values to 
satisfy SrxlevCell 1 > 
SrxlevCell 2, such that 
camping on Cell 1 is 
guaranteed 


Tl 


Ro 


dBm 


P01 (FFS) 


PI 2 (FFS) 


Power P1 2 shall be assigned 
values to satisfy RCell 1 < 
RCell 2. 
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Table 8.1.3.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS changes Cell 1 and Cell 2 level 
according to the row "T1 " in table 8.1 .3.3.3.2- 
1.. 










2 


SS transmits an RRCConnectionRelease 
message to release the RRC Connection. 


<— 


RRCConnectionRelease 


- 


- 


3 


SS waits for [x1] ms + 5s. 


- 


- 


- 


- 


4 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


4 


Check: Is there any random access requests 
from the UE on Cell 1? 


- 


- 


1 


P 



8.1 .3.3.3.3 Specific message contents 

Table 8.1.3.3.3.3-1 Systemlnformation BlockTypeS ior Cells 1 and Cell 2 (pre-test conditions) 



Derivation Path: 36.508 Table 4.4.3.3-2 | 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockTypeS ::= SEQUENCE { 








cellReselectionlnfoCommon SEQUENCE { 








t-ReselectionEUTRAN 


7 






} 
















1 









8.1 .3.4 RRC Connection Release: redirection to another E-UTRAN frequency 

Editor's note: this test case description is not based on 36.331 v8.3.0. 



8.1.3.4.1 



(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an RRCConnectionRelease message including an IE Redirectionlnformation with E- 
UTRA-CarrierFreq different from the frequency UE was on in RRC_CONNECTED state} 

then { UE enters RRC_IDLE state on new frequency included in IE Redirectionlnformation } 



8.1.3.4.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clause 5.3.8.3 and TS 
36.304, clause 5.2.7. 

[TS 36.331, clause 5.3.8.3] 

The UE shall: 

1> delay the following actions defined in this sub-clause 60ms from the moment the RRCConnectionRelease 
message was received or optionally when lower layers indicate that the receipt of the RRCConnectionRelease 
message has been successfully acknowledged, whichever is earlier; 

1> indicate the release of the RRC connection to upper layers; 

1> release all radio resources; 

1> If the RRCConnectionRelease message includes the redirectionlnformation : 
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2> select a suitable cell on the (E-UTRA or inter-RAT) frequency indicated by the redirectionlnformation in 
accordance with the cell selection process as specified in TS 36.304; 

1> enter RRC_IDLE. 

[TS 36.304, clause 5.2.7] 

On transition from RRC_CONNECTED to RRC_IDLE, a UE shall attempt to camp on the last cell for which it was in 
RRC_CONNECTED or a cell/any cell of set of cells or any cell of frequency assigned by RRC in the state transition 
message... 



8.1.3.4.3 
8.1.3.4.3.1 



Test description 
Pre-test conditions 



System Simulator: 

2 cells on different E-UTRA frequencies: 
Cell 1 (default parameters) serving cell 
Cell 3 (TBD parameters) inter-frequency cell 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on cell 1. 



8.1.3.4.3.2 



Test procedure sequence 



Table 8.1.3.4.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS changes Cell 1 and Cell 3 parameters so 
that Cell 3 meets cell selection criteria. 


- 


- 


- 


- 


2 


SS transmits an RRCConnectionRelease 
message (IE Redirectionlnformation including 
EUTRA-CarrierFreq). 


<— 


RRCConnectionRelease 








EXCEPTION: The steps 3 and 4 below are 
repeated for a duration of [xljms + 5s. 










3 


SS sends a paging message on Cell 1 


<— 


Paging 


1 


- 


4 


Check if UE response to paging 


— > 


RRCConnectionRequest 


1 


F 


5 


Check: Does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC IDLE state on Cell 3. 






1 


P 
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8.1 .3.4.2.3.3 Specific message contents 

Table 8.1 .3.4.2.3.3-1 RRCConnectionRelease message (step 2, Table 8.1 .3.4.3.2-1) 



Derivation Path: 36.508 table 4.6.1 .2-14 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRelease ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRelease-r8 SEQUENCE { 








redirectionlnformation ::= CHOICE { 








eutra-CarrierFreq 


EARFCN of cell 3 






1 








} 








} 








} 








Table 8.1.3.4.2.3.3-2 SystemlnformationBlockType4 ior Cell 3 


Derivation Path: 36.331 clause 6.2.2 


Information Element 


Value/remark 


Comment 


Condition 


System lnformationBlockType4 ::= SEQUENCE { 








servingFreqCellReselectionlnfo SEQUENCE { 








s-NonlntraSearch 


Not present 






threshServingLow 




FFS 




cellReselecetionPriority 









} 








intraFreqNeighbouringCellList 


Not needed in this TC 


FFS 




intraFreqBlacklistedCellList 


Not present 














} 








Table 8.1.3.4.2.3.3-3 SystemlnformationBlockTypeS ior Cell 3 


Derivation Path: 36.331 clause 6.2.2 


Information Element 


Value/remark 


Comment 


Condition 


SystemlnformationBlockTypeS ::= SEQUENCE { 








interFreqCarrierFreqList SEQUENCE (SIZE 
(1 ..maxFreq)) OF SEQUENCE { 


1 entry 






eutra-CarrierFreq[0] 


EARFCN of cell 1 






threshX-High[0] 




FFS 




threshX-Low[0] 




FFS 




measurementBandwidth[0] 




FFS 




cellReselectionPriority[0] 


1 






q-OffsetFreq[0] 




FFS 




interFreqNeighbouringCellList[0] 


Not present 






interFreqBlacklistedCellList [0] 


Not present 






} 
















} 









8.1 .3.5 RRC Connection Release: success (with priority information) 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41 and 36.304 v8.3.0 i.e. after RAN#41. 



8.1.3.5.1 



(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_IDLE state having received an RRCConnectionRelease message with the IE 
interFreqPriorityList with higher priority frequency} 
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ensure that { 

when { UE detects the cell re-selection criteria is met for the cell which belongs to the higher 
priority frequency } 

then { UE reselects the cell which belongs to the higher priority frequency } 
} 

8.1.3.5.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.8.3, and 
TS 36.304, clause 5.2.4.1,5.2.4.2,5.2.4.5. 

[TS 36.331, clause 5.3.8.3] 

The UE shall: 

1> delay the following actions defined in this sub-clause 60ms from the moment the RRCConnectionRelease 
message was received or optionally when lower layers indicate that the receipt of the RRCConnectionRelease 
message has been successfully acknowledged, whichever is earlier; 

1> If the RRCConnectionRelease message includes the idleModeMobilityControlInfo: 

2> store the idleModeMobilityControlInfo 

2> If the t320 is included: 

3> start timer T320, with the timer value set according to the value of t320; 
1> else: 



1> If the releaseCause is set to 'load balancing TAU required' 

1> If the RRCConnectionRelease message includes the redirectionlnformation : 

1> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 

[TS 36.304, clause 5.2.4.1] 

Absolute priorities of different E-UTRAN frequencies or inter-RAT frequencies may be provided to the UE in the 
system information or in the RRC message releasing the RRC connection. If priorities are assigned via dedicated 
signalling, the UE shall ignore all the priorities provided in system information. The UE shall delete priorities provided 
by dedicated signalling when: 

- the UE enters RRC_CONNECTED state; or 

the optional validity time of dedicated priorities (T320) expires; or 

a PLMN selection is performed on request by NAS [5]. 

NOTE: Equal priorities between RATs are not supported. 

UE shall only perform reselection evaluation for E-UTRAN frequencies and inter-RAT frequencies that are given in 
system information and for which the UE has a priority provided. 

[TS 36.304, clause 5.2.4.2] 

Following rules are used by the UE to limit needed measurements: 

If SServingCell > Sintrasearch, UE may choose to not perform intra-frequency measurements. 

If SServingCell <= Sintrasearch, UE shall perform intra-frequency measurements. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 252 ETSI TS 136 523-1 V8.0.1 (2009-01) 

The UE shall apply the following rules for E-UTRAN inter-frequencies and inter-RAT frequencies which are 
indicated in system information and for which the UE has priority provided as defined in 5.2.4. 1 : 

o For an E-UTRAN inter-frequency or inter-RAT frequency with a reselection priority higher than 
the reselection priority of the current E-UTRA frequency the UE shall perform measurements of 
higher priority E-UTRAN inter- frequencies or inter-RAT frequencies according to [10]. 

o For an E-UTRAN inter-frequency with a equal or lower reselection priority than the reselection 
priority of the current E-UTRA frequency and for inter-RAT frequency with lower reselection 
priority than the reselection priority of the current E-UTRAN frequency: 

■ If SservingCeii > Snonintrasearch UE may choosc not to perform mcasurcmcnts of E-UTRAN 
inter-frequencies or inter-RAT frequencies of equal or lower priority. 

■ If SservingCeii <= Snonintrasearch the UE shall perform measurements of E-UTRAN inter- 
frequencies or inter-RAT frequencies cells of equal or lower priority according to [10]. 

Where SservingCeii is the Srxlev-value of the serving cell. 

[TS 36.304, clause 5.2.4.5] 

Criteria 1 : the SnnnServingCdi.x of a cell on evaluated frequency is greater than Thresh^, high during a time interval 
TreselectionRAx; 

Cell reselection to a cell on a higher priority E-UTRAN frequency or inter-RAT frequency than serving frequency shall 
be performed if: 

A cell of a higher priority E-UTRAN frequency or inter-RAT frequency fulfills criteria 1 ; and 

more than 1 second has elapsed since the UE camped on the current serving cell. 

Cell reselection to a cell on a lower priority E-UTRAN frequency or inter-RAT frequency than serving frequency shall 
be performed if: 

No cell on serving frequency or on a higher priority E-UTRAN frequency or inter-RAT frequency than serving 
frequency fulfills the criteria 1 ; and 

SseivingCeii < Thrcshserving, low and the SnonServingCeii.x of a ccll of a lowcr priority E-UTRAN frequency or inter-RAT 
frequency is greater than Threshx !□„ during a time interval TreselectionRAx; and 

more than 1 second has elapsed since the UE camped on the current serving cell. 

Cell reselection to a cell on an equal priority E-UTRAN frequency shall be based on ranking for Intra-frequency Cell 
Reselection as defined in sub-clause 5.2.4.6. 

SnonSeivingCeii.x IS the Srxlcv-valuc of a evaluated cell. In all the above criteria the value of TreselectionRAx is scaled when 
the UE is in the medium or high mobility state as defined in subclause 5.2.4.6. If more than one cell meets the above 
criteria, the UE shall reselect a cell ranked as the best cell among the cells meeting the criteria on the highest priority 
RAT or the highest priority frequency if the highest priority RAT is E-UTRA. 

Note: It is FFS what the definition is for SnonServingCell,x for cdma2000 RATs. 

8.1.3.5.3 Test description 

8.1.3.5.3.1 Pre-test conditions 

System Simulator: 

- Celll,Cell3andCell5 

UE: 
None. 
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Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 



8.1.3.5.3.2 



Test procedure sequence 



Table 8.1.3.5.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.1.3.5.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 3 


Cell 5 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P03 (FFS) 


P05 (FFS) 


Shall be assigned values to 

satisfy SrxleVcell 1 > Smtrasearch, 

such that camping on Cell 1 is 
guaranteed 


Tl 


Ro 


dBm 


P01 (FFS) 


P13(FFS) 


P15(FFS) 


Power P13 and PI 5 shall be 
assigned values to satisfy 
Threshx, high < both Srxlevceiis 
and Srxlevceii 5 



Table 8.1.3.5.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an RRCConnectionRelease 
message including the IE interFreqPriohtyList. 


<- 


RRCConnectionRelease 


- 


- 


2 


Wait for 5 s for the UE to enter E-UTRA 
RRC IDLE state on Cell 1. 


- 


- 


- 


- 


3 


The SS changes Cell 1 , Cell 3 and Cell 5 level 
according to the row "T1 " in table 8.1 .3.5.3.2-1 . 


- 


- 


- 


- 


4 


Wait for 5 s for the UE to perform cell 
reselection procedure. 


- 


- 


- 


- 


5 


Make the UE initiate an outgoing call. 


- 


- 


- 


- 


6 


Check: Is there any random access requests 
from the UE on Cell 5? 


- 


- 


1 


P 



8.1 .3.5.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.1.3.5.3.3-1 : RRCConnection Release (step 2, Table 8.1.3.5.3.2-1) 



Derivation Path: 36.508 Table 4.6.1-14 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRelease ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE { 








rrcConnectionRelease-r8 SEQUENCE { 








idleModeMobilityControllnfo SEQUENCE { 








interFreqPriorityList SEQUENCE (SIZE 
(L.tnaxFreq)) OF SEQUENCE { 


2 entries 






eutra-CarrierFreq[1] SEQUENCE { 








earfcn-DL 


Same downlinl< EARFCN 
as used for Cell 3 






1 








cellReselectionPriority[1 ] 


1 






eutra-CarrierFreq[2] SEQUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 5 






1 








cellReselectionPriority[2] 


5 






} 








geran-FreqPriorityList 


Not present 






utra-FDD-FreqPriorityList 


Not present 






utra-TDD-FreqPrJorityList 


Not present 






hrpd-BandClassPriorityList 


Not present 






oneXRTT-BandClassPriorityLlst 


Not present 






1320 


Not present 






} 








1 








} 








} 








} 









8.1 .3.6 RRC Connection Release: redirection from E-UTRAN to UTRAN 

Editor's note: this test case description is not based on 36.331 v8.3.0. 
8.1.3.6.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an RRCConnectionRelease message including an IE redirect ionlnformat ion with 
utra-CarrierFreq UTRA frequency } 

then { UE enters RRC_IDLE state on UTRA frequency included in IE redirect ionlnformat ion } 



8.1.3.6.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clause 5.3.8.3 and TS 
36.304, clause 5.2.7. The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.331, clause 5.3.8.3] 

The UE shall: 

1> delay the following actions defined in this sub-clause 60ms from the moment the RRCConnectionRelease 
message was received or optionally when lower layers indicate that the receipt of the RRCConnectionRelease 
message has been successfully acknowledged, whichever is earlier; 

1> indicate the release of the RRC connection to upper layers; 
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1> release all radio resources; 

1> If the RRCConnectionRelease message includes the redirectionlnformation : 

2> select a suitable cell on the (E-UTRA or inter-RAT) frequency indicated by the redirectionlnformation in 
accordance with the cell selection process as specified in TS 36.304; 

1> enter RRCJDLE. 

[TS 36.304, clause 5.2.7] 

On transition from RRC_CONNECTED to RRC_IDLE, a UE shall attempt to camp on the last cell for which it was in 
RRC_CONNECTED or a cell/any cell of set of cells or any cell of frequency assigned by RRC in the state transition 
message... 



8.1.3.6.3 
8.1.3.6.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- one E-UTRA cell and one UTRA cell : 

Cell 1 (default parameters) E-UTRA serving cell 
- Cell 5 (TBD parameters) UTRA cell 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) on cell 1 according to [18]. 
Editor's note: SS Test conditions to be finalised 



8.1.3.6.3.2 



Test procedure sequence 



Table 8.1.3.6.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS changes Cell 5 parameters so that Cell 5 
meets cell selection criteria. 






- 


- 


2 


SS transmits an RRCConnectionRelease 
message (IE Redirectionlnformation including 
UTRA-CarrierFreq). 


<— 


RRCConnectionRelease 








EXCEPTION: The steps 3 and 4 below are 
repeated for a duration of [xljms + 5s. 










3 


SS sends a paging message on Cell 1 


<— 


Paging 


- 


- 


4 


Check if UE response to paging 


— > 


RRCConnectionRequest 


1 


F 


5 


Check: the test result of CALL generic 
procedure indicates that UE is in UTRA 
RRC IDLE state on Cell (. 






1 


P 
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8.1 .3.6.3.3 Specific message or IE contents 

Table 8.1.3.6.3.3-1 RRCConnectionRelease message (step 2, Table 8.1.3.6.3.2-1) 



Derivation Path: 36.508 table 4.6.1 .2-14 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionRelease ::= SEQUENCE { 








criticalExtensions CHOICE { 








rrcConnectionRelease-r8 SEQUENCE { 








redirectionlnformation ::= CHOICE { 








interRAT-target CHOICE { 








utra 


UARFCN of cell 2 






} 








} 








} 








1 








} 









Table 8.1.3.6.3.3-2 Priority Info List IE for cell 5 

In the "Priority Info List" IE within system information, priority of UARCN of cell 5 is 0, priority of EARFCN of cell 1 
isl. 

Note: It is FFS in which System Information Block type this IE will be introduced, or if a new System 
Information Block type will be created. 

The exact definition of IE "Priority Info List" definition is FFS. 

8.2 RRC Connection Reconfiguration 

8.2.1 Radio Bearer Establishment 

8.2.1 .1 RRC Connection Reconfiguration / Radio Bearer Establishment for transition 

from RRCJDLE to RRC_CONNECTED: Success (Default bearer, early 
bearer establishment) 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RP#41 + R2-085979. 



8.2.1.1.1 



(1) 



Test Purpose (TP) 



with { UE having completed the RRC connection establishment procedure } 
ensure that { 

when { SS sends in sequence a SecurityModeCommand and an RRCConnectionReconfiguration message 
then { UE establishes the initial security configuration in accordance with the received 
securityConfiguration included in SecurityModeCommand and successfully completes the connection 
reconfiguration } 



8.2.1.1.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.1.2, 
5.3.5.3 and 5.3.10.3. The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.331, clause 5.1.2] 

The UE shall: 

1> process the received messages in order of reception by RRC, i.e. the processing of a message shall be 
completed before starting the processing of a subsequent message; 
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NOTE: E-UTRAN may initiate a subsequent procedure prior to receiving the UEs response of a previously 
initiated procedure. 



[TS 36.331, clause 5.3.1.1] 



After having initiated the initial security activation procedure, E-UTRAN initiates the establishment of SRB2 and of 
radio bearers carrying user data (DRBs), i.e. E-UTRAN may do this prior to receiving the confirmation of the initial 
security activation from the UE. In any case, E-UTRAN will apply both ciphering and integrity protection for the RRC 
connection reconfiguration messages used to establish SRB2 and DRBs. 



[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> If ihQ RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 



NOTE: If the RRCConnectionReconfiguration message includes the establishment of radio bearers others than 
SRBl, the UE may start using these radio bearers immediately, i.e. there is no need to wait for an 
outstanding acknowledgment of the SecurityModeComplete message. 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.10.3] 

The UE shall: 

1> if the received radioResourceConfiguration includes the drb-ToAddModifyList: 

2> for each drb-Identity value included in the drb-ToAddModifyList that is not part of the current UE 
configuration (DRB establishment): 

3> establish a PDCP entity and configure it with the current security configuration and in accordance with 
the received PDCP-Configuration IE; 

3> establish an RLC entity in accordance with the received RLC-Configuration IE; 

3> establish a DTCH logical channel in accordance with the received LogicalChannelConfig IE; 



8.2.1.1.3 


Test description 


8.2.1.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 
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Preamble: 

The UE is in state Registered, Idle mode (state 2) according to [18]. 



8.2.1.1.3.2 



Test procedure sequence 



Table 8.2.1.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


Make UE attempting an outgoing call 


- 


- 


- 


- 


2 


UE transmits an RRCConnectionRequest 
message. 


— > 


RRCConnectionRequest 


- 


- 


3 


SS transmit a RRCConnectionSetup message 


<— 


RRCConnectionSetup 


- 


- 


4 


The UE transmits a 

RRCConnectionSetupComplete \.o confirm the 
successful completion of the connection 
establishment. 


— > 


RRCConnectionSetupCompiete 






5 


SS transmits a SecurityModeCommand 
message to activate AS security. 


<-- 


SecurityModeCommand 


- 


- 


6 


Before the security activation procedure 
completes, the SS transmits an 
RRCConnectionReconfiguration message to 
establish a data radio bearer. 


<-- 


RRCConnectionReconfiguration 






7 


Check: does the UE transmit a 
SecurityModeComplete message? 


— > 


SecurityModeCompiete 


1 


P 


8 


Check: does the UE transmit a 
RRCConnectionReconfigurationComplete 
message to confirm the establishment of data 
radio bearer? 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


9 


Check: does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC CONNECTED state? 






1 





8.2.1.1.3.3 



Specific message contents 



Table 8.2.1 .1 .3.3-1 RRCConnectionReconfiguration (step 6, Table 8.2.1 .1 .3.2-1) 

Derivation Path: 36.508 table 4.6.1-6, condition SRB2-DRB(1 , 0) 



8.2.1 .2 RRC Connection Reconfiguration / Radio Bearer Establishment for transition 

from RRCJDLE to RRC_CONNECTED: Failure (Default bearer) 

Editor's Note: This section is based on 36.331 v8.2.0 i.e. after RAN#40 + R2-083795. 



8.2.1.2.1 
(1) 



Test Purpose (TP) 



with { UE having completed the initial security activation procedure } 
ensure that { 

when { UE is unable to comply with a received RRCConnectionReconfiguration message 
then { UE initiates the connection re-establishment procedure } 



8.2.1.2.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.5.3, 
5.3.5.5, 5.3.7.2, 5.3.7.3, 5.3.7.4 and 5.3.7.9. 
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[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 
1> If the RRCConnectionReconfiguration message includes the ue-Relatedlnformation: 

2> set the C-RNTl to the value of the newUE-Identity, if received; 
1> If the RRCConnectionReconfiguration message includes the nas-Dedicatedlnformation: 

2> Forward the nas-Dedicatedlnformation to upper layers; 
1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

NOTE: If the RRCConnectionReconfiguration message includes the establishment of radio bearers others than 
SRBl, the UE may start using these radio bearers immediately, i.e. there is no need to wait for an 
outstanding acknowledgment of the SecurityModeComplete message. 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.5.5] 

The UE shall: 

1> If the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration 
message: 

2> continue using the configuration used prior to the reception of RRCConnectionReconfiguration message; 

2> initiate the connection re-establishment procedure as specified in 5.3.7, upon which the connection 
reconfiguration procedure ends. 

NOTE: If the UE is unable to comply with part of the configuration, it does not apply any part of the 
configuration i.e. there is no partial success/ failure. 

[TS 36.331, clause 5.3.7.2] 

The UE shall only initiate the procedure when security has been activated. The UE initiates the procedure when one of 
the following conditions is met: 

1> after having detected radio link failure, in accordance with 5.3.1 1; or 

1> upon handover failure, in accordance with 5.3.5.6; or 

1> when RLC indicates that the maximum number of retransmissions has been reached, as specified in TS 36.322 
[7]; or 

1> upon an RRC connection reconfiguration failure, in accordance with 5.3.5.5. 

Upon initiation of the procedure, the UE shall: 

1> stop timer T310, if running; 

1> stop timer T312, if running; 

1> start timer T311; 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> select a suitable cell in accordance with the cell selection process as specified in [4]; 
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[TS 36.331, clause 5.3.7.3] 

Upon (re-)entry of service area while T31 1 is running, the UE shall: 

1> Upon selecting an E-UTRA cell: 

2> stop timer T3 11 ; 

2> start timer T301; 

2> initiate transmission of the RRCConnectionReestablishmentRequest message in accordance with 5.3.7.4; 

NOTE 1 : The criteria for re-entry of service area specified in 5.3. 1 1 .4. 

NOTE 2: This procedure applies also if the UE returns to the source cell 

1> Upon selecting an inter-RAT cell: 

2> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 

[TS 36.331, clause 5.3.7.4] 

The UE shall set the contents of RRCConnectionReestablishmentRequest message as follows: 

1> set the IE ue-ldentity as follows: 

2> set the c-RNTl to the C-RNTl used in the source cell (handover failure case) or used in the cell in which the 
trigger for the re-establishment occurred (other cases); 

2> set the cellldentity to the Physical layer identity of the source cell (handover failure case) or of the cell in 
which the trigger for the re-establishment occurred (other cases); 

2> set the authenticationCode to a MAC-1 calculated over: 

3> the C-RNTl used in the source cell (handover failure case) or used in the cell in which the trigger for the 
re-establishment occurred (other cases); 

3> the Physical layer identity of the source cell (handover failure case) or of the cell in which the trigger for 
the re-establishment occurred (other cases) 

3> the identity of the target cell (details FES) 

1> set the IE reestablishmentCause as follows (details FFS): 

Editor's note: SA3 indicated that a size of around 16 may be used for the MAC-1 i.e. using truncation (see R2- 
081917). 

The UE shall submit the RRCConnectionReestablishmentRequest message to lower layers for transmission. 

[TS 36.331, clause 5.3.7.9] 

Upon receiving the RRCConnectionReestablishmentReject message, the UE shall: 

1> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 

Editor's note: It is up to upper layers to take further action. To facilitate this, the cause of the release may need to be 
indicated to upper layers. 

8.2.1.2.3 Test description 

8.2.1.2.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 
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UE: 

None. 

Preamble: 

The UE is in state Registered, Idle mode (state 2) on Cell 1 according to [18]. 
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8.2.1.2.3.2 



Test procedure sequence 



Table 8.2.1.2.3.2-1: Main behaviour (FFS) 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a Paging message including 
a matched identity. 


<— 


Paging 


- 


- 


2 


The UE transmits an RRCConnectionRequest 
message. 


— > 


RRCConnectionRequest 


- 


- 


3 


The SS transmits an RRCConnectionSetup 
message. 


<— 


RRCConnectionSetup 


- 


- 


4 


The UE transmits an 

RRCConnectionSetupComplete message to 
confirm the successful completion of the 
connection establishment. 


— > 


RRCConnectionSetupComplete 






5 


The SS transmits a SecurityModeCommand 
message to activate AS security. 


<— 


SecurityModeCommand 


- 


- 


6 


The UE transmits a SecurityModeComplete 
message and establishes the initial security 
configuration. 


— > 


SecurityModeComplete 






7 


The SS transmits an 

RRCConnectionReconfiguration, which lacks 
the lEs required for the DRB setup. 


<— 


RRCConnectionReconfiguration 


1 




8 


Check: Does the UE transmit an 

RRCConnectionReestablishmentRequest 

message. 


--> 


RRCConnectionReestablishment 
Request 


1 


P 


9 


The SS transmits an 
RRCConnectionReestablishmentReject 
message to release the RRC connection. 


<-- 


RRCConnectionReestablishment 
Reject 


1 




10 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC IDLE state? 






1 





8.2.1 .2.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.2.1.2.3.3-1: Paging (step 1, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-2: RRCConnectionRequest (step 2, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-3: RRCConnectionSetup (step 3, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-4: RRCConnectionSetupComplete (step 4, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-5: SecurityModeCommand (step 5, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-6: SecurityModeComplete (step 6, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-7: RRCConnectionReconfiguration (step 7, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-8: RRCConnectionReestablishmentRequest (step 8, Table 8.2.1.2.3.2-1) 

FFS 
Table 8.2.1.2.3.3-9: RRCConnectionReestablishmentReject (step 9, Table 8.2.1.2.3.2-1) 

FFS 

8.2.1 .3 RRC Connection Reconfiguration / Radio Bearer Establishment: Success 

(Dedicated bearer) 

8.2.1 .3.1 Test Purpose (IP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { SS sends an RRCConnectionReconfiguration message including a drb-Identity that is not part 
of the current UE configuration and a nas-Dedicatedlnformation } 

then { UE successfully establish the radio bearer according to IE radioResourceConfiguration } 
} 

8.2.1.3.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.3 
and 5.3.10.3. 

The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



263 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 
2>perform the Radio resource configuration procedure as specified in 5.3.10; 

1> If the RRCConnectionReconfiguration message includes the nas-Dedicatedlnformation: 
2> Forward the nas-Dedicatedlnformation to upper layers; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.10.3] 

The UE shall: 

1> if the received radioResourceConfiguration includes the drb-ToAddModifyList: 

2> for each drb-Identity value included in the drb-ToAddModifyList that is not part of the current UE 
configuration (DRB establishment): 

3> establish a PDCP entity in accordance with the received PDCP-Configuration IE; 

3> establish an RLC entity in accordance with the received RLC-Configuration IE; 

3> establish a DTCH logical channel in accordance with the received LogicalChannelConfig IE; 



8.2.1.3.3 


Test description 


8.2.1.3.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 

8.2.1 .3.3.2 Test procedure sequence 

Table 8.2.1.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
establish a data radio bearer. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


3 


The UE transmits an ULInformationTransfer 
message. 


— > 


UL Information Transfer 


- 


- 


4 


Check: the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC CONNECTED state. 






1 





£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



264 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



8.2.1 .3.3.3 Specific message contents 

Table 8.2.1.3.3.3-1 RRCConnectionReconfiguration (step 1, Table 8.2.1.3.3.2-1) 



Derivation Path: 36.508 table 4.6.1-6, condition DRB(1,0) | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHQICE { 








c1 CHQICE{ 








rrcConnectionReconfiguration-r8 SEQUENCE { 








nas-Dedicatedlnformation 


octet string 


ACTIVATE 
DEDICATED EPS 
BEARER 
CONTEXT 
REQUEST 
according 36.508 
table 4.7.3-3 




} 








1 








1 








} 









8.2.1 .4 RRC Connection Reconfiguration / Radio Bearer Establishment: Failure 

(Dedicated bearer) 

Editor's Note: This section is based on 36.331 v8.2.0 i.e. after RAN#40 + R2-083795. 



8.2.1.4.1 
(1) 



Test Purpose (TP) 



with { UE having completed the radio bearer establishment and initial security activation procedure 

} 

ensure that { 

when { UE is unable to comply with a received RRCConnectionReconfiguration message } 

then { UE performs the connection re-establishment procedure } 



8.2.1.4.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.5.3, 
5.3.5.5, 5.3.7.2, 5.3.7.3, 5.3.7.4, 5.3.7.5 and 5.3.7.6. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInfonnation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 
1> If the RRCConnectionReconfiguration message includes the ue-Relatedlnfonnation: 

2> set the C-RNTl to the value of the newUE-Identity, if received; 
1> If the RRCConnectionReconfiguration message includes the nas-Dedicatedlnformation: 

2> Forward the nas-Dedicatedlnformation to upper layers; 
1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 
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NOTE: If the RRCConnectionReconfiguration message includes the establishment of radio bearers others than 
SRBl, the UE may start using these radio bearers immediately, i.e. there is no need to wait for an 
outstanding acknowledgment of the SecurityModeComplete message. 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.5.5] 

The UE shall: 

1> If the UE is unable to comply with (part of) the configuration included in the RRCConnectionReconfiguration 
message: 

2> continue using the configuration used prior to the reception of RRCConnectionReconfiguration message; 

2> initiate the connection re-establishment procedure as specified in 5.3.7, upon which the connection 
reconfiguration procedure ends. 

NOTE: If the UE is unable to comply with part of the configuration, it does not apply any part of the 
configuration i.e. there is no partial success/ failure. 

[TS 36.331, clause 5.3.7.2] 

The UE shall only initiate the procedure when security has been activated. The UE initiates the procedure when one of 
the following conditions is met: 

1> after having detected radio link failure, in accordance with 5.3.11; or 

1> upon handover failure, in accordance with 5.3.5.6; or 

1> when RLC indicates that the maximum number of retransmissions has been reached, as specified in TS 36.322 
[7]; or 

1> upon an RRC connection reconfiguration failure, in accordance with 5.3.5.5. 

Upon initiation of the procedure, the UE shall: 

1> stop timer T310, if running; 

1> stop timer T312, if running; 

1> start timer T311; 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> select a suitable cell in accordance with the cell selection process as specified in [4]; 

[TS 36.331, clause 5.3.7.3] 

Upon (re-)entry of service area while T311 is running, the UE shall: 

1> Upon selecting an E-UTRA cell: 

2> stop timer T3 11 ; 

2> start timer T301; 

2> initiate transmission of the RRCConnectionReestablishmentRequest message in accordance with 5.3.7.4; 
NOTE 1: The criteria for re-entry of service area specified in 5.3.1 1.4. 
NOTE 2: This procedure applies also if the UE returns to the source cell 
1> Upon selecting an inter-RAT cell: 

2> perform the actions upon moving from RRC_CONNECTED to RRC_IDLE as specified in 5.3.12. 
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[TS 36.331, clause 5.3.7.4] 

The UE shall set the contents of RRCConnectionReestablishmentRequest message as follows: 

1> set the IE ue-ldentity as follows: 

2> set the c-RNTl to the C-RNTl used in the source cell (handover failure case) or used in the cell in which the 
trigger for the re-establishment occurred (other cases); 

2> set the cellldentity to the Physical layer identity of the source cell (handover failure case) or of the cell in 
which the trigger for the re-establishment occurred (other cases); 

2> set the authenticationCode to a MAC-1 calculated over: 

3> the C-RNTl used in the source cell (handover failure case) or used in the cell in which the trigger for the 
re-establishment occurred (other cases); 

3> the Physical layer identity of the source cell (handover failure case) or of the cell in which the trigger for 
the re-establishment occurred (other cases) 

3> the identity of the target cell (details PES) 

1> set the IE reestablishmentCause as follows (details EES): 

Editor's note: SA3 indicated that a size of around 16 may be used for the MAC-I i.e. using truncation (see R2- 
081917). 

The UE shall submit the RRCConnectionReestablishmentRequest message to lower layers for transmission. 

[TS 36.331, clause 5.3.7.5] 

NOTE: Prior to this, lower layers allocate a C-RNTL For further details see TS 36.321 [6]; 
The UE shall: 

1> Stop timer T301; 

1> resume SRBl after reconfiguring it in accordance with the received radioResourceConfiguration and as 
specified in 5.3. 10; 

Editor's note: It has been agreed that the procedure is the same irrespective of whether the UE returns to the same 
cell. So, e.g. the UE always derives a new AS base-key (KeNB) 

1> configure lower layers to re-activate integrity protection using the previously configured algorithm immediately, 
i.e. integrity protection shall be applied to all subsequent messages received and sent by the UE, including the 
message used to indicate the successful completion of the procedure; 

1> configure lower layers to apply ciphering using the previously configured algorithm immediately, i.e. ciphering 
shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate 
the successful completion of the procedure; 

1> send the RRCConnectionReestablishmentComplete message as specified in 5.3.7.6; 

1> Resume the RRC connection with the restriction that the use of all radio bearers other than SRBl is suspended 
until a subsequent RRCConnectionReconfiguration message is received; 

Editor's note: A subsequent RRC connection reconfiguration procedure is used to re-activate the measurements. The 
concerned RRCConnectionReconfiguration message can, for the RLC/MAC & measurement 
configuration, either apply delta or full signalling. In case of 'full signalling' the UE completely deletes 
the existing configuration and replaces this with the newly received configuration. The use of 'full 
signalling' for PDCP is FES, but should be aligned with what is agreed for handover. Upon successful 
connection re-establishment, the UE applies the same rules to the measurement configuration as defined 
for the case of handover. 

[TS 36.331, clause 5.3.7.6] 

The UE shall submit the RRCConnectionReestablishmentComplete message to lower layers for transmission. 
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8.2.1.4.3 


Test description 


8.2.1.4.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.2.1.4.3.2 



Test procedure sequence 



Table 8.2.1.4.3.2-1: Main behaviour (FFS) 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message, 
which lacks the lEs required for the DRB 
setup. 


<— 


RRCConnectionReconfiguration 


1 




2 


Check: Does the UE transmit an 

RRCConnectionReestablishmentRequest 

message? 


— > 


RRCConnectionReestablishment 
Request 


1 


P 


3 


The SS transmits an 
RRCConnectionReestablishment message. 


<— 


RRCConnectionReestablishment 


1 


- 


4 


Check: Does the UE transmit an 

RRCConnectionReestablishmentComplete 

message. 


— > 


RRCConnectionReestablishment 
Complete 


1 


P 


5 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state? 






1 





8.2.1 .4.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 

Table 8.2.1 .4.3.3-1 : RRCConnectionReconfiguration (step 1 , Table 8.2.1 .4.3.2-1) 

FFS 

Table 8.2.1.4.3.3-2: RRCConnectionReestablishmentRequest (step 2, Table 8.2.1.4.3.2-1) 

FFS 

Table 8.2.1.4.3.3-3: RRCConnectionReestablishment (step 3, Table 8.2.1.4.3.2-1) 

FFS 

Table 8.2.1.4.3.3-4: RRCConnectionReestablishmentComplete (step 4, Table 8.2.1.4.3.2-1) 

FFS 
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8.2.1 .7 RRC Connection Reconfiguration / Radio Bearer Establishment: Success 

(SRB2) 

8.2.1 .7.1 Test Purpose (TP) 

with { UE in E-UTRA RRC_CONNECTED state without SRB2 } 
ensure that { 

when { SS sends an RRCConnectionReconf iguration message including SRB2 configuration } 
then { UE successfully establish the signalling radio bearer } 
} 

8.2.1.7.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.3, 
and 5.3.10.1. 

The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.10.10; 



1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.10.1] 

The UE shall: 

1> if the received radioResourceConfiguration includes the srb-ToAddModifyList: 

2> for each srb-Identity value included in the srb-ToAddModifyList that is not part of the current UE 
configuration (SRB establishment): 

3> if the rlc-Configuration is set to 'explicit': 

4> establish an RLC entity in accordance with the received RLC-Configuration IE; 

3> else if the rlc-Configuration is set to 'default': 

4> establish an RLC entity in accordance with the default configuration applicable for this srb-identity as 
specified in 9.2.1; 

3> if the logicalChannelConfig is set to 'explicit': 

4> establish a DCCH logical channel in accordance with the received LogicalChannelConfig IE; 

3> else if the logicalChannelConfig is set to 'default': 

4> establish a DCCH logical channel in accordance with the default configuration applicable for this srb- 
identity as specified in 9.2. 1 ; 

8.2.1.7.3 Test description 

8.2.1.7.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 
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Preamble: 

The UE is in state Registered, Idle Mode (State 2) according to [18]. 

8.2.1 .7.3.2 Test procedure sequence 

Table 8.2.1.7.3.2-1: Main behaviour 



St 


Procedure 


U-S 


lUlessage Sequence 
lUlessage 


TP 


Verdict 


1-7 


Generic Radio Bearer Establishment (State 3) 
step 1 to 7. 






- 


- 


8 


The SS transmits an 

RRCConnectionReconfiguration message to 
establish SRB2. 


<— 


RRCConnectionReconfiguration 






9 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
ompiete 


1 


P 


10 


Check: the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC CONNECTED state. 






1 


P 



8.2.1.7.3.3 



Specific message contents 

Table 8.2.1.7.3.3-1 : RRCConnectionReconfiguration (step 8) 



Derivation Path: 36.508 table 4.6.1-6, condition SRB2-DRB(1, 0) 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








CI CHOICE{ 








rrcConnectionReconfiguration-r8 SEQUENCE { 








radioResourceConfiguration SEQUENCE { 








srb-ToAddModifyList SEQUENCE (SIZE (1..2)) 
OF SEQUENCE { 








srb-ToAddModify[1] SEQUENCE! 








rIc-Configuration CHOICE { 








explicit 


RLC-Configuration-NON- 
DEFAULT-SRB2 






} 








} 








1 








1 








} 








} 








} 








1 








} 
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Table 8.2.1.7.3.3-2: RLC-Configuration-NON-DEFAULT-SRB2 (step 8) 



Derivation Path: 36.331 clauses 6.3.2, 9.2.1.2 | 


Information Element 


Value/remark 


Comment 


Condition 


RLC-Configuration-NON-DEFAULT-SRB2 ::= 
CHOICE! 








am SEQUENCE { 








ul-AM-RLC SEQUENCE { 








t-PollRetransmit 


ms100 






pollPDU 


p16 






poll Byte 


kbSOO 






maxRetxTlireshold 


t4 






} 








dl-AM-RLC SEQUENCE { 








t- Reordering 


ms100 






t-StatusProhibit 


ms200 






} 








} 








1 









8.2.2 RacJio Resource Reconfiguration 

8.2.2.1 RRC Connection Reconfiguration / Radio Resource Reconfiguration: 

Success 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RP#41 + R2 -085979.8.2.2. 1.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an RRCConnectionReconfigration message including a radioResourceConfiguration 
with SRB, DRB, transport channel and physical channel reconfiguration } 
then { UE reconfigures the data and signalling radio bearers } 



8.2.2.1.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.5.3, 
5.3.10.1, 5.3.10.3, 5.3.10.4 and 5.3.10.6. 

The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 



1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.10.1] 

The UE shall: 

1> if the received radioResourceConfiguration includes the srb-ToAddModifyList: 
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2> for each srb-Identity value included in the srb-ToAddModifyList that is part of the current UE configuration 
(SRB reconfiguration): 

3> if the rlc-Configuration is set to 'explicit': 

4> reconfigure the RLC entity in accordance with the received RLC-Configuration IE; 

3> else if the rlc-Configuration is set to 'default': 

4> reconfigure the RLC entity in accordance with the default configuration applicable for this srb-identity 
as specified in 9.2. 1 . 1 ; 

3> if the logicalChannelConfig is set to 'explicit': 

4> reconfigure the DCCH logical channel in accordance with the received LogicalChannelConfig IE; 

3> else if the logicalChannelConfig is set to 'default': 

4> reconfigure the DCCH logical channel in accordance with the default configuration applicable for this 
srb-identity as specified in 9.2.1.1; 

NOTE 1 : 'Infinity' is the only applicable value for the prioritizedBitRate for SRB 1 and SRB2 

NOTE 2: AM is the only applicable RLC mode for SRBl and SRB2 

[TS 36.331, clause 5.3.10.3] 
The UE shall: 

1> if the received radioResourceConfiguration includes the drb-ToAddModifyList: 

2> indicate the establishment of the DRB(s) to upper layers; 

2> for each drb-Identity value included in the drb-ToAddModifyList that is part of the current UE configuration 
(DRB reconfiguration): 

3> reconfigure the PDCP entity in accordance with the received PDCP-Configuration IE; 

3> reconfigure the RLC entity in accordance with the received RLC-Configuration IE; 

3> reconfigure the DTCH logical channel in accordance with the received LogicalChannelConfig IE; 

[TS 36.331, clause 5.3.10.4] 

The UE shall: 

1> if the received radioResourceConfiguration includes the IE mac-MainConfig: 

2> if the mac-MainConfig is set to 'explicit': 

3> if the received mac-MainConfig includes the dl-SCH-Configuration: 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> if the received mac-MainConfig includes the ul-SCH-Configuration: 

4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> if the mac-MainConfig includes drx-Configuration: 

4> if the drx-Configuration is set to 'disable' : 

5> disable the DRX functionality; 

5> release the DRX configuration. 

4> else if the drx-Configuration includes shortDRX and shortDRX is set to 'disable': 



ETSI 



3GPP TS 36.523-1 version 8.0.1 Release 8 272 ETSI TS 136 523-1 V8.0.1 (2009-01) 

5> disable the short DRX functionality; 

5> release short DRX configuration; 

3> if the mac-MainConfig includes timeAlignmentTimerDedicated: 

4> apply the timeAlignmentTimerDedicated; 

3> if the mac-MainConfig includes phr-Configuration: 

4> if the phr-Configuration is set to 'disable' : 

5> disable the power headroom reporting functionality; 

2> else if the mac-MainConfig is set to 'default': 

3> reconfigure the mac-MainConfig in accordance with the default configuration as specified in 9.2.2; 

[TS 36.331, clause 5.3.10.6] 

The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> if the antennalnformation is included and set to 'explicit' : 

3> reconfigure the antenna configuration in accordance with the received AntennalnformationDedicated; 

2> else if the antennalnformation is included and set to 'default': 

3> reconfigure the antenna configuration in accordance with the default configuration 'Antenna Information 
Dedicated' as specified in 9.2.4; 

2> if physicalConfigDedicated includes IE cqi-Reporting and cqi-Reporting includes IE cqi-ReportingPeriodic 
and the configuration is set to disable: 

3> deactivate any uplink resources used for periodic CQI Reporting, if active; 

3> release the cqi-ReportingPeriodic configuration; 
2> if physicalConfigDedicated includes the IE soundingRsUl-Config and the configuration is set to disable: 

3> deactivate any uplink resources used for Sounding if active; 

3> release the soundingRsUl-Config configuration. 
2> if physicalConfigDedicated includes the IE schedulingRequestConfig and the configuration is set to disable: 

3> deactivate any uplink resources used for Scheduling Request if active; 

3> release the schedulingRequestConfig configuration. 

Test description 
Pre-test conditions 



8.2.2.1.3 




8.2.2.1.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 
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Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.2.2.1.3.2 



Test procedure sequence 



Table 8.2.2.1.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


The SS transmits an 

RRCConnectionReconfiguration containing a 
radioResourceConfiguration \N\\h SRBs, DRB, 
transport channel and physical channel 
reconfiguration. 


<— 


RRCConnectionReconfiguration 






2 


Check: does the UE transmit a 
RRCConnectionReconfigurationComplete 
message to confirm the reconfiguration of the 
radio resources? 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


3 


Check: does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC CONNECTED state? 











8.2.2.1.3.3 



Specific message contents 

Table 8.2.2.1.3.3-1 RRCConnectionReconfiguration 



Derivation Path: 36.508 table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








radioResourceConfiguration 


RadioResourceConfigDe 
dicated-RECONFIG 






1 








} 








} 








} 








Table 8.2.2.1.3.3-2 RadioResourceConfigDedicated-RECONFIG {step 1) 


Derivation Path: 36.331 clause 6.3.2 


Information Element 


Value/remark 


Comment 


Condition 


RadioResourceConfigDedicated-RECONFIG ::= 
SEOUENCE { 








srb-ToAddlVlodifyList 


FFS 






drb-ToAddlVlodifyList 


FFS 






drb-ToReleaseList 


Not present 






transportChannelConfig CHOICE { 








default 


FFS 






1 








physicalConfiqDedicated 


FFS 






} 









£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 274 ETSI TS 136 523-1 V8.0.1 (2009-01) 

8.2.2.2 RRC Connection Reconfiguration / SRB/DRB Reconfiguration: Success 

8.2.2.2.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state} 
ensure that { 

when { UE receives a RRCConnectionReconfiguration message) 

then { UE sets parameters according to the value of IE and sends 
RRCConnectionReconfigurationComplete message } 
} 

8.2.2.2.2 Conformance requirements 

References: The conformance requirements covered in the current TC is specified in: TS 36.331, clauses 5.3.5.3, 
5.3.9.1,5.3.9.3, and 9.2.2.1. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobility Controllnformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> if the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 
2>perform the Radio resource configuration procedure as specified in 5.3.10; 
[TS 36.331, clause 5.3.10.1] 
The UE shall: 

1> if the received radioResourceConfiguration includes the srb-ToAddModifyList: 

2> for each srb-Identity value included in the srb-ToAddModifyList that is not part of the current UE 
configuration (SRB establishment): 

3> if the rlc-Configuration is set to 'explicit': 

4> establish an RLC entity in accordance with the received RLC-Configuration IE; 

3> else if the rlc-Configuration is set to 'default': 

4> establish an RLC entity in accordance with the default configuration applicable for this srb-identity as 
specified in 9.2.1; 

3> if the logicalChannelConfig is set to 'explicit': 

4> establish a DCCH logical channel in accordance with the received LogicalChannelConfig IE; 

3> else if the logicalChannelConfig is set to 'default': 

4> establish a DCCH logical channel in accordance with the default configuration applicable for this srb- 
identity as specified in 9.2. 1 ; 

2> for each srb-Identity value included in the srb-ToAddModifyList that is part of the current UE configuration 
(SRB reconfiguration): 

3> if the rlc-Configuration is set to 'explicit': 

4> reconfigure the RLC entity in accordance with the received RLC-Configuration IE; 

3> else if the rlc-Configuration is set to 'default': 

4> reconfigure the RLC entity in accordance with the default configuration applicable for this srb-identity 
as specified in 9.2. 1 . 1 ; 

3> if the logicalChannelConfig is set to 'explicit': 
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4> reconfigure the DCCH logical channel in accordance with the received LogicalChannelConfig IE; 

3> else if the logicalChannelConfig is set to 'default': 

4> reconfigure the DCCH logical channel in accordance with the default configuration applicable for this 
srb-identity as specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.3] 

The UE shall: 

1> if the received radioResourceConfiguration includes the drb-ToAddModifyList: 

2> for each drb-Identity value included in the drb-ToAddModifyList that is part of the current UE configuration 
(DRB reconfiguration): 

3> reconfigure the PDCP entity in accordance with the received PDCP-Configuration IE; 

3> if the rlc-ReestablishmentRequest is included, re-establish RLC for the corresponding DRB; 

3> reconfigure the RLC entity in accordance with the received RLC-Configuration IE; 

3> reconfigure the DTCH logical channel in accordance with the received LogicalChannelConfig IE; 



8.2.2.2.3 


Test Description 


8.2.2.2.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 
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8.2.2.2.3.2 



Test procedure sequence 

Table 8.2.2.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an RRConnectionReconfiguration 
message including 

radioResourceReconfiguration which includes 
srb- ToAddModifyList 


<— 


RRCConnectionReconfiguration 






2 


Check: UE transmits 
RRCConnectionReconfigurationComplete. 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


3 


Check: UE modifies SRBs using the 
parameters according to the value of IE sent in 
step 1 . 






1 


P 


4 


SS transmits RRCConnectionReconfiguration 
message including 

radioResourceReconfiguration which includes 
drb- ToAddModifyList 


<— 


RRCConnectionReconfiguration 






5 


Check: UE transmits 
RRCConnectionReconfigurationComplete. 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


6 


Check: UE modifies DRBs using the 
parameters according to the value of IE sent in 
step 4. 






1 


P 


7 


SS transmits an RCConnectionReconfiguration 
message including 

radioResourceReconfiguration which includes 
rIc-ReestablistimentRequest 


<— 


RRCConnectionReconfiguration 






8 


Check: UE transmits 

RRCConnectionReconfigurationComplete and 
re-establish ric entities. 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


9 


Check: UE re-establish RLC entities. 


- 


- 


1 


P 



8.2.2.2.3.3 Specific message or IE contents 

Table 8.2.2.2.3.3-1 RRCConnectionReconfiguration (step 1, Table 8.2.2.2.3.2-1) 



FFS 



FFS 



FFS 



FFS 



FFS 



FFS 



Table 8.2.2.2.3.3-2 RRCConnectionReconfigurationComplete {step 2, Table 8.2.2.2.3.2-1) 



Table 8.2.2.2.3.3-3 RRCConnectionReconfiguration (step 4, Table 8.2.2.2.3.2-1) 



Table 8.2.2.2.3.3-4 RRCConnectionReconfigurationComplete (step 5, Table 8.2.2.2.3.2-1) 



Table 8.2.2.2.3.3-5 RRCConnectionReconfiguration (step 7, Table 8.2.2.2.3.2-1) 



Table 8.2.2.2.3.3-6 RRCConnectionReconfigurationCompiete (step 8, Table 8.2.2.2.3.2-1) 
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8.2.3 Radio Bearer Release 

8.2.3.1 RRC Connection Reconfiguration / Radio Bearer Release: Success 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RP#41 + R2 -085979.8.2.3. 1.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including a drb-ToReleaseList } 

then { for each drb-Identity release the PDCP entity and RLC entity and DTCH logical channel; 
and indicate release of the DRB{s) to upper layers } 
} 

8.2.3.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.5.3 
and 5.3.10.2. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration, upon which the procedure ends; 

[TS 36.331, clause 5.3.10.2] 

The UE shall: 

1> if the received radioResourceConfiguration includes the drb-ToReleaseList: 

2> for each drb-Identity value included in the drb-ToReleaseList that is part of the current UE configuration 
(DRB release): 

3> release the PDCP entity; 

3> release the RLC entity; 

3> release the DTCH logical channel; 

2> indicate the release of the DRB(s) and the eps-Beare ridentity of the released DRB(s) to upper layers; 



8.2.3.1.3 


Test description 


8.2.3.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 
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Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 

8.2.3.1 .3.2 Test procedure sequence 

Table 8.2.3.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS to transmits an 

RRCConnectionReconfiguration message with 
a drb-ToReleaseList 


<— 


RRCConnectionReconfiguration 






2 


Checl<: Does the UE transmits a 

RRCConnectionReconfigurationComplete 

message? 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


3 


Checl<: does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC CONNECTED state? 











8.2.3.1.3.3 



Specific message contents 

Table 8.2.3.1.3.3-1 : RRCConnectionReconfiguration (step 1) 



Derivation Path: 36.508 table 4.6.1-6 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEQUENCE { 








radioResourceConfiguration 


RadioResourceConfigDe 
dicated-DRB-RELEASE 






} 








} 








1 








} 









Table 8.2.3.1.3.3-2: RadioResourceConfigDedicated-DRB-RELEASE (step 1) 



Derivation Path: 36.331 clause 6.3.2 | 


Information Element 


Value/remark 


Comment 


Condition 


RadioResourceConfigDedicated-DRB-RELEASE ::= 
SEQUENCE { 








srb-ToAddModifyLlst 


Not present 






drb-ToAddModifyList 


Not present 






drb-ToReleaseList SEQUENCE (SIZE (L.maxDRB)) 
OF SEQUENCE { 


1 entry 






drb-ldentity[1] 


FFS 






} 








transportChannelConfig 


Not present 






physicalConfigDedicated 


Not present 






} 









8.2.4 Handover 



8.2.4.1 



RRC Connection Reconfiguration / Handover: Success (Dedicated preamble) 



Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 
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8.2.4.1 .1 Test Purpose (TP) 
(1) 

with { UE having completed the radio bearer establishment and initial security activation procedure 
and performed the intra frequency measurement} 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControlInformation with an IE rach-ConfigDedicated } 

then { UE transmits an RRCConnectionReconfigurationComplete message } 
} 

8.2.4.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4, 
5.3.10.4 and 5.3.10.5. 

[TS 36.331, clause 5.3.5.4] 

If the RRCConnectionReconfiguration message includes the mobilityControlInformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T3 10 and T3 12, if running; 

1> start timer T304 with the timer value set to t304, as included in the mobilityControlInformation; 

1> request PDCP to initiate the PDCP Re -establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HFN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTl to the value of the newUE-Identity; 

l> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

l> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 

targetCellldentity; 

l> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
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1> If the KRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> If the RRCConnectionReconfiguration message includes the measurementConfigumtion: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the physicalConfigDedicated is included in the RRCConnectionReconfiguration: 

3> If the UE needs the SEN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SEN of the target cell; 

3> else: 

4> apply the new PUCCH and Sounding RS configuration; 

2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 

2> the procedure ends. 

[TS 36.331, clause 5.3.10.4] 

The UE shall: 

1> if the received radioResourceConfiguration includes the IE MAC-MainConfiguration: 

2> if the current UE configuration does not include a DL-SCH transport channel configuration (DL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit': 

4> establish an DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2. LI; 

2> else: 

3> if the transportChannelConfig is set to 'explicit': 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 
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2> if the current UE configuration does not include a UL-SCH transport channel configuration (UL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit' 

4> establish an UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit' 

4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.5] 

The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> if the current UE configuration does not include a physical channel configuration (physical channel 
establishment): 

3> establish the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> else: 

3> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

1> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 

8.2.4.1.3 Test description 

8.2.4.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 

UE: 

None. 

Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 
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8.2.4.1.3.2 



Test procedure sequence 



Table 8.2.4.1.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.2.4.1.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy exit condition for event 
A3(M2 + Hys<M1). 


T1 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy entry condition for event 
A3(M2-Hys>M1). 



Table 8.2.4.1.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra frequency measurement. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


-> 


RRCConnectionReconfigurationC 
omplete 






3 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T1 " in table 8.2.4.1 .3.2-1 . 


- 


- 


- 


- 


4 


The UE transmits a MeasurementReport 
message to report event A3 with the measured 
RSRP value for Cell 2. 


-> 


MeasurementReport 






5 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2. 


<— 


RRCConnectionReconfiguration 






6 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message on Cell 2 using dedicated preamble 
to confirm the successful completion of the 
intra frequency handover? 


-> 


RRCConnectionReconfigurationC 
omplete 


1 


P 


7 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2? 






1 
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8.2.4.1.3.3 



Specific message contents 



Table 8.2.4.1.3.3-1 RRCConnectionReconfiguration (step 1, Table 8.2.4.1.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration SEOUENCE { 








measObjectToRemoveList 


Not present 






measObjectToAddlVlodifyList SEOUENCE 
(SIZE (1 ..maxObjectId)) OF SEOUENCE { 


1 entry 






measObjectld[1] 


IdlVleasQbjectEUTRA- 
M01 






measObject[1] CHOICE! 








measObjectEUTRA 


MeasObjectEUTRA-M01 






} 








} 








reportConfigToRemoveList 


Not present 






reportConfigToAddModifyList SEQUENCE 
(SIZE (L.maxReportConfigld)) OF SEQUENCE { 


1 entry 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






reportConfig[1] CHOICE! 








reportConfigEUTRA 


ReportConfigEUTRA- 
RC1 






1 








} 








measldloRemoveList 


Not present 






measldloAddModifyLlst SEQUENCE (SIZE 
(L.maxMeasId)) OF SEQUENCE { 


1 entry 






measld[1] 


1 






measObjectld[1] 


IdlVleasObjectEUTRA- 
M01 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






1 








quantityConfig 


FFS 






measGapConfig 


Not present 






s-l\/leasure 


Not present 






hrpd-PreRegistrationlnfo 


Not present 






mbsfn-NeighbourCellConfig 


Not present 






speedDependentParameters 


Not present 






} 








radioResourceConfiguration 


Not present 






} 








1 








} 








} 
















MeasObjectEUTRA ::= SEQUENCE { 


MeasObjectEUTRA-MOl 






eutra-Carrierlnfo SEOUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 2 






} 








measurementBandwidth 


Not present 






offsetFreq 


dBO 






cellsToRemoveList 


Not present 






cellsToAddModifyList 


Not present 






blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyLlst 


Not present 






cellForWhichToReportCGI 


Not present 






} 
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ReportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 






triggerType CHOICE { 








event SEQUENCE { 








eventid CHQICE { 








eventAS SEQUENCE { 








a3-0ffset 


FFS 






} 








1 








hysteresis 


FFS 






timeToTrigger 


FFS 






} 








} 








triggerQuantity 


rsrp 






reportQuantity 


sameAsTriqqerOuantity 






maxReportCells 


8 






reportlnterval 


Not present 






reportAmount 


Not present 














} 
















Table 8.2.4.1.3.3-2 MeasurementReport {step 4, Table 8.2.4.1.3.2-2) 


Derivation Path: 36.508, Table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


IVIeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-r8 SEQUENCE { 








measuredResults SEQUENCE { 








measid 


1 






measResultServing 


FFS 






mobilitylVleasResults CHOICE { 








measResultListEUTRA SEQUENCE (SIZE 
(1 ..maxCellReport)) OF SEQUENCE { 


1 entry 






physicalCellldentity[1] 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






globalCellldentity[1] 


Not present 






measResultEUTRA[1l SEQUENCE { 








rsrpResult 


FFS 






rsrqResult 


Not present 














} 








1 








} 








} 








} 








} 








1 








} 









£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



285 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



Table 8.2.4.1.3.3-3 RRCConnectionReconfiguration (step 5, Table 8.2.4.1.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6, condition RBC-HO | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HQ 






targetCellldentity 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






eutra-CarrierFreq 


Not present 






rach-ConfigDedicated SEQUENCE { 








ra-Preamblelndex 


FFS 






ra-Resourcelndex 


Not present 




FDD 


ra-Resourcelndex 


FFS 




TDD 


} 








} 








securityConfiguration 


SecurityConfiguration-HQ 






ue-Relatedlnformation 


UE-Relatedlnformation- 
HO 






} 








1 








1 








} 









Condition 


Explanation 


FDD 


FDD cell environment 


TDD 


TDD cell environment 



8.2.4.2 RRC Connection Reconfiguration / Handover: Success (Common preamble) 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.2.4.2.1 



(1) 



Test Purpose (TP) 



with { UE having completed the radio bearer establishment and initial security activation procedure 
and performed the intra frequency measurement } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControllnformation without an IE rach-ConfigDedicated } 

then { UE transmits an RRCConnectionReconfigurationComplete message } 



8.2.4.2.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4, 
5.3.10.4 and 5.3.10.5. 

[TS 36.331, clause 5.3.5.4] 



If the RRCConnectionReconfiguration message includes the mobilityControllnformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304 with the timer value set to t304, as included in the mobilityControllnformation; 
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1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HFN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTI to the value of the newUE-Identity; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> \f ihQ RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If Ihe physicalConfigDedicated is included in the RRCConnectionReconfiguration message: 
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3> If the UE needs the SFN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SFN of the target cell; 
3> else: 

4> apply the new PUCCH and Sounding RS configuration; 
2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 
2> the procedure ends. 

[TS 36.331, clause 5.3.10.4] 
The UE shall: 

1> if the received radioResourceConfiguration includes the IE MAC-MainConfiguration: 

2> if the current UE configuration does not include a DL-SCH transport channel configuration (DL-SCH 

establishment): 

3> if the transportChannelConfig is set to 'explicit': 

4> establish an DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit': 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the DL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

2> if the current UE configuration does not include a UL-SCH transport channel configuration (UL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit' 

4> establish an UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit' 

4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.5] 
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The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> if the current UE configuration does not include a physical channel configuration (physical channel 
establishment): 

3> establish the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> else: 

3> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

1> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 



8.2.4.2.3 

8.2.4.2.3.1 

System Simulator: 
- Cell 1 and Cell 2 

UE: 
None. 



Test description 
Pre-test conditions 



Preamble: 

The UE is in state Generic RB Established (state 3) on cell 1 according to [18]. 



8.2.4.2.3.2 



Test procedure sequence 



Table 8.2.4.2.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.2.4.2.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy exit condition for event 
A3(M2 + Hys<M1). 


T1 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy entry condition for event 
A3(M2-Hys>M1). 
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Table 8.2.4.2.3.2-2: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra frequency measurement. 


<- 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


-> 


RRCConnectionReconfigurationC 
ompiete 






3 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T1 " in table 8.2.4.2.3.2-1 . 


- 


- 


- 


- 


4 


The UE transmits a MeasurementReport 
message to report event A3 with the measured 
RSRP value for Cell 2. 


-> 


MeasurementReport 






5 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2. 


<- 


RRCConnectionReconfiguration 






6 


Check: The UE transmits an 
RRCConnectionReconfigurationComplete 
message on Cell 2 using common preamble to 
confirm the successful completion of the intra 
frequency handover. 


-> 


RRCConnectionReconfigurationC 
ompiete 


1 


P 


7 


Check: the test result of CALL generic 
procedure indicates that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2. 






1 


P 
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8.2.4.2.3.3 



Specific message contents 



Table 8.2.4.2.3.3-1 RRCConnectionReconfiguration (step 1 , Table 8.2.4.2.3.2-2) 



iDerivation Path: 36.508, Table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration SEOUENCE { 








measObjectToRemoveList 


Not present 






measObjectToAddlVlodifyList SEOUENCE 
(SIZE (1 ..maxObjectId)) OF SEOUENCE { 


1 entry 






measObjectld[1] 


IdlVleasQbjectEUTRA- 
M01 






measObject[1] CHOICE! 








measObjectEUTRA 


MeasObjectEUTRA-M01 






} 








} 








reportConfigJoRemoveList 


Not present 






reportConfigToAddModifyList SEQUENCE 
(SIZE (L.maxReportConfigld)) OF SEQUENCE { 


1 entry 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






reportConfig[1] CHOICE! 








reportConfigEUTRA 


ReportConfigEUTRA- 
RC1 






1 








} 








measldloRemoveList 


Not present 






measldloAddModifyLlst SEQUENCE (SIZE 
(L.maxMeasId)) OF SEQUENCE { 


1 entry 






measld[1] 


1 






measObjectld[1] 


IdlVleasObjectEUTRA- 
M01 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






1 








quantityConfig 


FFS 






measGapConfig 


Not present 






s-l\/leasure 


Not present 






hrpd-PreRegistrationlnfo 


Not present 






mbsfn-NeighbourCellConfig 


Not present 






speedDependentParameters 


Not present 






} 








radioResourceConfiguration 


Not present 






} 








1 








} 








} 
















MeasObjectEUTRA ::= SEQUENCE { 


MeasObjectEUTRA-MOl 






eutra-Carrierlnfo SEOUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 2 






} 








measurementBandwidth 


Not present 






offsetFreq 


dBO 






cellsToRemoveList 


Not present 






cellsToAddModifyList 


Not present 






blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyLlst 


Not present 






cellForWhichToReportCGI 


Not present 






} 
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ReportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 






triggerType CHOICE { 








event SEQUENCE { 








eventid CHQICE { 








eventAS SEQUENCE { 








a3-0ffset 


FFS 






} 








1 








hysteresis 


FFS 






timeToTrigger 


FFS 






} 








} 








triggerQuantity 


rsrp 






reportQuantity 


sameAsTriqqerOuantity 






maxReportCells 


8 






reportlnterval 


Not present 






reportAmount 


Not present 














} 
















Table 8.2.4.2.3.3-2 MeasurementReport {step 4, Table 8.2.4.2.3.2-2) 


Derivation Path: 36.508, Table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


IVIeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-r8 SEQUENCE { 








measuredResults SEQUENCE { 








measid 


1 






measResultServing 


FFS 






mobilitylVleasResults CHOICE { 








measResultListEUTRA SEQUENCE (SIZE 
(1 ..maxCellReport)) OF SEQUENCE { 


1 entry 






physicalCellldentity[1] 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






globalCellldentity[1] 


Not present 






measResultEUTRA[1l SEQUENCE { 








rsrpResult 


FFS 






rsrqResult 


Not present 














} 








1 








} 








} 








} 








} 








1 








} 
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Table 8.2.4.2.3.3-3 RRCConnectionReconfiguration (step 5, Table 8.2.4.2.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6, condition RBC-HO | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HQ 






targetCellldentity 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






eutra-CarrierFreq 


Not present 






} 








securityConfiguration 


SecurityConfiguration-HQ 






ue-Relatedlnformation 


UE-Relatedlnformation- 
HO 






} 








1 








1 








} 









8.2.4.3 RRC Connection Reconfiguration / Handover: success (intra-cell, security 

reconfiguration) 



Editor's Note: This section is based on TS 36.331 v82.0 RAN#40 + R2-083795. 



8.2.4.3.1 
(1) 



Test Purpose (TP) 



with { UE having completed the radio bearer establishment and initial security activation procedure 

} 

ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE SecurityConfiguration } 

then { UE transmits an RRCConnectionReconfigurationComplete message } 

} 

8.2.4.3.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4. 

[TS 36.331, clause 5.3.5.4] 

NOTE 1: The UE should perform the handover as soon as possible following the reception of the RRC message 

triggering the handover, which could be before confirming successful reception (HARQ and ARQ) of this 

message. 

If the RRCConnectionReconfiguration message includes the mobilityControllnformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304; 

1> If the RRCConnectionReconfiguration message includes the radioRe source Configuration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTI to the value of the newUE-Identity; 

1> indicate the occurrence of handover to PDCP; 

1> if the eutra-CarrierFreq is included: 
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2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uphnk bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> If the RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm immediately, i.e. the indicated 
integrity protection configuration shall be applied to all subsequent messages received and sent by the UE, 
including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm immediately, i.e. the indicated ciphering 
configuration shall be applied to all subsequent messages received and sent by the UE, including the message 
used to indicate the successful completion of the procedure; 

1> reset MAC and re-establish RLC for all RBs that are estabhshed; 

NOTE 2: The handhng of the radio bearers after the successful completion of handover, e.g. the re-transmission of 
unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of the SN and the 
HEN, is specified in [8]. 

1> synchronise to the DL of the target cell; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration; 

3> perform the physical layer reconfiguration related actions applicable upon successfully completing the 
handover as specified in 5.3.10.5; 

2> the procedure ends. 

Editor's note: It has been agreed that the UE is not required to determine the SEN of the target cell by acquiring 
system information from that cell. 
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Editor's note The handling of the radio configuration is covered by the general reconfiguration procedure. It has 

been agreed that the configuration used in the target cell may either be specified as a delta to the one used 
in the serving cell or by providing the full configuration (signalling details are FFS) 

Editor's note Currently it is specified that the keylndicator always needs to be provided upon handover as a result of 
which the securityConfiguration becomes mandatory in case of handover. If however the 
securityConfiguration would be optional in case of handover, the case the IE is not included needs to be 
covered also. 



8.2.4.3.3 


Test description 


8.2.4.3.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 
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8.2.4.3.3.2 



Test procedure sequence 



Table 8.2.4.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate tlie EPS 
authentication and AKA procedure. 


<— 


DL Information Transfer 






2 


The UE transmits an AUTHENTICATION 
RESPONSE message and re-establishes 
mutual authentication. 


— > 


ULInformationTransfer 






3 


The SS transmits a NAS SECURITY MODE 
COIVIMAND message to reactivate NAS 
security. 


<— 


DL Information Transfer 






4 


The UE transmits a NAS SECURITY MODE 
COMPLETE message and re-establishes the 
security configuration. 


— > 


UL Information Transfer 






5 


The SS transmits a 

RRCConnectionReconfiguration message to 
perform intra cell handover and security 
reconfiguration. 


<— 


RRCConnectionReconfiguration 






6 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message using the security key indicated by 
the IE Keylndicator to confirm the successful 
completion of the intra cell handover and 
security reconfiguration? 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


7 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state? 






1 




1 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


DL Information Transfer 






2 


The UE transmits an AUTHENTICATION 
RESPONSE message and re-establishes 
mutual authentication. 


— > 


UL Information Transfer 






3 


The SS transmits a NAS SECURITY MODE 
COMMAND message to reactivate NAS 
security. 


<— 


DLInformationTransfer 






4 


The UE transmits a NAS SECURITY MODE 
COMPLETE message and re-establishes the 
security configuration. 


— > 


UL Information Transfer 






5 


The SS transmits a 

RRCConnectionReconfiguration message to 
perform intra cell handover and security 
reconfiguration. 


<— 


RRCConnectionReconfiguration 







8.2.4.3.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 

Table 8.2.4.3.3.3-1 : RRCConnectionReconfiguration (step 5, Table 8.2.4.3.3.2-1) 

FFS 

Table 8.2.4.3.3.3-2: RRCConnectionReconfigurationComplete (step 6, Table 8.2.4.3.3.2-1) 

FFS 



8.2.4.5 



RRC Connection Reconfiguration / Handover (all parameters included) 



Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 
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8.2.4.5.1 Test Purpose (TP) 

with { UE having completed the radio bearer establishment and initial security activation procedure 
and performed the intra frequency measurement } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControlInformation will all parameters included } 

then { UE transmits an RRCConnectionReconfigurationComplete message } 
} 

8.2.4.5.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331 clauses 5.3.5.4, 
5.3.10.4 and 5.3.10.5. 

[TS 36.331, clause 5.3.5.4] 



If the RRCConnectionReconfiguration message includes the mobilityControUnfonnation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304 with the timer value set to t304, as included in the mobilityContromlnformation; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HFN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTl to the value of the newUE-Identity; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> If the RRCConnectionReconfiguration message includes the securityConfiguration: 
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2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the physicalConfigDedicated is included in the RRCConnectionReconfiguration message: 

3> If the UE needs the SEN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SEN of the target cell; 

3> else: 

4> apply the new PUCCH and Sounding RS configuration; 

2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 

2> the procedure ends. 



[TS 36.331, clause 5.3.10.4] 

The UE shall: 

1> if the received radioResourceConfiguration includes the IE MAC-MainConfiguration: 

2> if the current UE configuration does not include a DL-SCH transport channel configuration (DL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit': 

4> establish an DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2. LI; 

2> else: 

3> if the transportChannelConfig is set to 'explicit': 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 
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2> if the current UE configuration does not include a UL-SCH transport channel configuration (UL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit' 

4> establish an UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit' 

4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.5] 

The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> if the current UE configuration does not include a physical channel configuration (physical channel 
establishment): 

3> establish the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> else: 

3> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

1> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 

8.2.4.5.3 Test description 

8.2.4.5.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 

UE: 

None. 

Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 
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8.2.4.5.3.2 



Test procedure sequence 



Table 8.2.4.5.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.2.4.5.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy exit condition for event 
A3(M2 + Hys<M1). 


T1 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy entry condition for event 
A3(M2-Hys>M1). 



Table 8.2.4.5.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message to 
setup intra frequency measurement. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of intra 
frequency measurement. 


-> 


RRCConnectionReconfigurationC 
ompiete 






3 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T1 " in table 8.2.4.5.3.2-1 . 


- 


- 


- 


- 


4 


The UE transmits a MeasurementReport 
message to report event A3 with the measured 
RSRP value for Cell 2. 


-> 


MeasurementReport 






5 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2. 


<~ 


RRCConnectionReconfiguration 






6 


Check: does the UE transmit an 
RRCConnectionReconfigurationComplete 
message to confirm the successful completion 
of the intra frequency handover? 


-> 


RRCConnectionReconfigurationC 
ompiete 


1 


P 


7 


Check: does the test result of CALL generic 
procedure indicates that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2? 






1 





8.2.4.5.3.3 Specific message contents 

Editors note:To be updated according to agreed RRC message structure. 
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Table 8.2.4.5.3.3-1 : RRCConnectionReconfiguration (step 1 , Table 8.2.4.6.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-8 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration SEOUENCE { 








measObjectToRemoveList 


Not present 






measObjectToAddlVlodifyList SEOUENCE 
(SIZE (1 ..maxObjectId)) OF SEOUENCE { 


1 entry 






measObjectld[1] 


IdMeasObjectEUTRA- 
M01 






measObject[1] CHOICE! 








measObjectEUTRA 


MeasObjectEUTRA-M01 






} 








} 








reportConfigloRemoveList 


Not present 






reportConfigToAddModifyList SEQUENCE 
(SIZE (L.maxReportConfigld)) OF SEOUENCE { 


1 entry 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






reportConfig[1] CHOICE! 








reportConfigEUTRA 


ReportConfigEUTRA- 
RC1 






} 








} 








measldloRemoveLlst 


Not present 






measldloAddModifyList SEOUENCE (SIZE 
(1 ..maxMeasId)) OF SEQUENCE { 


1 entry 






measld[1] 


1 






measObjectld[1] 


IdMeasObjectEUTRA- 
M01 






reportConfigld[1] 


IdReportConfJgEUTRA- 
RC1 






1 








quantityConfig 


FFS 






measGapConfig 


Not present 






s-IVIeasure 


Not present 






hrpd-PreRegistrationlnfo 


Not present 






mbsfn-NeighbourCellConfig 


Not present 






speedDependentParameters 


Not present 






} 








radioResourceConfiguration 


Not present 






1 








1 








} 








} 
















MeasObjectEUTRA ::= SEQUENCE { 


MeasObjectEUTRA-MQI 






eutra-Carrierlnfo SEOUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 2 






} 








measurementBandwidth 


Not present 






offsetFreq 


dBO 






cellsToRemoveLlst 


Not present 






cellsToAddModifyList 


Not present 






blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyList 


Not present 






cellForWhichToReportCGI 


Not present 






} 
















ReportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 
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triggerType CHOICE { 








event SEQUENCE { 








eventid CHOICE { 








eventAS SEQUENCE { 








a3-0ffset 


FFS 






} 








} 








hysteresis 


FFS 






timeToTriqqer 


FFS 






} 








} 








triggerOuantity 


rsrp 






reportOuantity 


sameAsTriggerQuantity 






maxReportCells 


8 






reportlnterval 


Not present 






reportAmount 


Not present 














} 
















Table 8.2.4.5.3.3-2: MeasurementReport (step 4) 


Derivation Path: 36.508, Table 4.6.1-5 


Information Element 


Value/remark 


Comment 


Condition 


IVIeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-r8 SEQUENCE { 








measuredResults SEQUENCE { 








measid 


1 






measResultServing 


FFS 






mobilitylVleasResults CHOICE { 








measResultListEUTRA SEQUENCE (SIZE 
(L.tnaxCellReport)) OF SEQUENCE { 


1 entry 






physicalCellldentity[1] 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






globalCellldentity[1] 


Not present 






measResultEUTRA[1] SEQUENCE { 








rsrpResult 


FFS 






rsrqResult 


Not present 














} 








} 








1 








1 








} 








} 








} 








} 
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Table 8.2.4.5.3.3-3: RRCConnectionReconfiguration (step 5, Table 8.2.4.6.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-8, condition RBC-HO 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControl Information SEQUENCE { 








targetCellldentity 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






eutra-CarrierFreq SEQUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 1 






earfcn-UL 


Same uplink EARFCN as 
used for Cell 1 




FDD 




Not present 




TDD 


} 








eutra-CarrierBandwIdth SEOUENCE { 








dl-Bandwidth 


Same downlink system 
bandwidth as used for 
Cell 1 






ul-Bandwitdli 


Same uplink system 
bandwidth as used for 
CelM 






1 








additionalSpectrumEmission 


Same 

additionalSpectrumEmiss 
ion as used for Cell 1 






t304 


mslOOO 






radioResourceConfigCommon SEOUENCE { 








rach-Configuration 


FFS 






prach-Configuration 


FFS 






pdsch-Configuration 


FFS 






pusch-Configuration 


FFS 






phich-Configuration 


FFS 






pucch-Configuration 


FFS 






soundingRsUI-Config 


FFS 






uplinl<PowerControl 


FFS 






antennalnformationCommon 


FFS 






tdd-Configuration 


Not present 




FDD 




FFS 




TDD 


} 








rach-ConfigDedicated 


Not present 






} 








securityConfiguration 


SecurityConfiguration-HO 






ue-Relatedlnformation 


UE-Relatedlnformation- 
HO 






} 








} 








} 








} 









Condition 


Explanation 


FDD 


FDD cell environment 


TDD 


TDD cell environment 
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8.2.4.6 RRC Connection Reconfiguration / Handover: Success (inter-frequency) 

8.2.4.6.1 Test Purpose (TP) 
(1) 

with { UE having completed the radio bearer establishment and initial security activation procedure 
and performed the inter frequency measurement } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControlInformation indicating a different E-UTRA frequency} 

then { UE transmits an RRCConnectionReconfigurationComplete message } 
} 

8.2.4.6.2 conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4, 
5.3.10.4 and 5.3.10.5. 

[TS 36.331, clause 5.3.5.4] 

If the RRCConnectionReconfiguration message includes the mobilityControlInformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304 with the timer value set to t304, as included in mobilityControInformation; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HEN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTl to the value of the newUE-Identity; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 

targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 
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2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> If the RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the physicalConfigDedicated is included in the RRCConnectionReconfigumtion message: 

3> If the UE needs the SEN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SEN of the target cell; 

3> else: 

4> apply the new PUCCH and Sounding RS configuration; 

2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 

2> the procedure ends. 

[TS 36.331, clause 5.3.10.4] 
The UE shall: 

1> if the received radioResourceConfiguration includes the IE MAC-MainConfiguration: 

2> if the current UE configuration does not include a DL-SCH transport channel configuration (DL-SCH 

establishment): 

3> if the transportChannelConfig is set to 'explicit': 

4> establish an DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit': 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 
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3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the DL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

2> if the current UE configuration does not include a UL-SCH transport channel configuration (UL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit' 

4> establish an UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit' 

4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the UL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.5] 

The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> if the current UE configuration does not include a physical channel configuration (physical channel 
establishment): 

3> establish the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> else: 

3> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

1> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 

8.2.4.6.3 Test description 

8.2.4.6.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 3 

UE: 
None. 
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Preamble: 

The UE is in state state Generic RB Established (state 3) on cell 1 according to [18]. 



8.2.4.6.3.2 



Test procedure sequence 



Table 8.2.4.6.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
is to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 

Table 8.2.4.6.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Celll 


Cell 3 


Remarl( 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that 
measurement results for Cell 1 (Ml) and 
Cell 3 (M3) satisfy exit condition for event 
A3(M3 + Hys<M1). 


T1 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and PI 2 shall be such that 
measurement results for Cell 1 (IVII) and 
Cell 3 (M3) satisfy entry condition for event 
A3(M3-Hys>M1). 



Table 8.2.4.6.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup inter frequency measurement. 


<- 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


-> 


RRCConnectionReconfigurationC 
omplete 






3 


The SS changes Cell 1 and Cell 3 parameters 
according to the row "T1 " in table 8.2.4.6.3.2-1 . 


- 


- 


- 


- 


4 


The UE transmits a MeasurementReport 
message to report event A3 with the measured 
RSRP value for Cell 3. 


-> 


MeasurementReport 






5 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform inter frequency 
handover to Cell 3. 


<— 


RRCConnectionReconfiguration 






6 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message on Cell 3 to confirm the successful 
completion of the inter frequency handover? 


-> 


RRCConnectionReconfigurationC 
omplete 


1 


P 


7 


Check: does the test result of CALL generic 
procedure indicates that the UE is in E-UTRA 
RRC CONNECTED state on Cell 3? 






1 
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8.2.4.6.3.3 



Specific message contents 



Table 8.2.4.6.2.3.3-1 RRCConnectionReconfiguration (step 1, Table 8.2.4.6.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration SEOUENCE { 








measObjectToRemoveList 


Not present 






measObjectToAddlVlodifyList SEOUENCE 
(SIZE (1 ..maxObjectId)) OF SEOUENCE { 


1 entry 






measObjectld[1] 


IdlVleasQbjectEUTRA- 
M01 






measObject[1] CHOICE! 








measObjectEUTRA 


MeasObjectEUTRA-M01 






} 








} 








reportConfigToRemoveList 


Not present 






reportConfigToAddModifyList SEQUENCE 
(SIZE (L.maxReportConfigld)) OF SEQUENCE { 


1 entry 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






reportConfig[1] CHOICE! 








reportConfigEUTRA 


ReportConfigEUTRA- 
RC1 






1 








} 








measldloRemoveList 


Not present 






measldloAddModifyLlst SEQUENCE (SIZE 
(L.maxMeasId)) OF SEQUENCE { 


1 entry 






measld[1] 


1 






measObjectld[1] 


IdlVleasObjectEUTRA- 
M01 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






1 








quantityConfig 


FFS 






measGapConfig 


Not present 






s-l\/leasure 


Not present 






hrpd-PreRegistrationlnfo 


Not present 






mbsfn-NeighbourCellConfig 


Not present 






speedDependentParameters 


Not present 






} 








radioResourceConfiguration 


Not present 






} 








1 








} 








} 
















MeasObjectEUTRA ::= SEQUENCE { 


MeasObjectEUTRA-MOl 






eutra-Carrierlnfo SEOUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 3 






} 








measurementBandwidth 


Not present 






offsetFreq 


dBO 






cellsToRemoveList 


Not present 






cellsToAddModifyList 


Not present 






blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyLlst 


Not present 






cellForWhichToReportCGI 


Not present 






} 
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ReportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 






triggerType CHOICE { 








event SEQUENCE { 








eventid CHQICE { 








eventAS SEQUENCE { 








a3-0ffset 


FFS 






} 








1 








hysteresis 


FFS 






timeToTrigger 


FFS 






} 








} 








triggerQuantity 


rsrp 






reportQuantity 


sameAsTriqqerOuantity 






maxReportCells 


8 






reportlnterval 


Not present 






reportAmount 


Not present 














} 
















Table 8.2.4.6.3.3-2 MeasurementReport (step 4, Table 8.2.4.6.3.2-2) 


Derivation Path: 36.508, Table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


IVIeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-r8 SEQUENCE { 








measuredResults SEQUENCE { 








measid 


1 






measResultServing 


FFS 






mobilitylVleasResults CHOICE { 








measResultListEUTRA SEQUENCE (SIZE 
(1 ..maxCellReport)) OF SEQUENCE { 


1 entry 






physicalCellldentity[1] 


PhysicalCellldentity of 
Cell 3 (see 36.508 clause 
4.4.4.3) 






globalCellldentity[1] 


Not present 






measResultEUTRA[1l SEQUENCE { 








rsrpResult 


FFS 






rsrqResult 


Not present 














} 








1 








} 








} 








} 








} 








1 








} 









£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



309 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



Table 8.2.4.6.2.3.3-3 RRCConnectionReconfiguration (step 5, Table 8.2.4.6.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6, condition RBC-HO 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HQ 






targetCellldentity 


PhysicalCellldentity of 
Cell 3 (see 36.508 clause 
4.4.4.3) 






eutra-CarrierFreq SEQUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 3 






earfcn-UL 


Not present 






} 








} 








securJtyConfiguration 


SecurityConfiguration-HO 






ue-Relatedlnformation 


UE-Relatedlnformation- 
HO 






} 








} 








} 








} 









8.2.4.7 RRC Connection Reconfiguration / Handover: Failure (Re-establishment 

successful) 



8.2.4.7.1 



Test Purpose (TP) 



(1) 

with { UE having completed the radio bearer establishment and initial security activation procedure 
and after receiving an RRCConnectionReconfiguration message including an IE 

mobilityControllnformation indicating a different E-UTRA cell having atempted intra frequency 
handover } 
ensure that { 

when { UE detects handover failure and the initial cell is selectable} 

then { UE performs an RRC connection re-establishment procedure and remains in the E-UTRA 
RRC CONNECTED state } 



8.2.4.7.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4, 
5.3.5.6, 5.3.7.2, 5.3.7.4, 5.3.7.5, 5.3.7.6 and 5.3.10.5. 

[TS 36.331, clause 5.3.5.4] 

If the RRCConnectionReconfiguration message includes the mobilityControllnformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304 with the timer value set to t304, as included in the mobilityControllnformation; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HEN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 
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1> If the KRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTI to the value of the newUE-Identity; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> If the RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 

I> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the physicalConfigDedicated is included in the RRCConnectionReconfiguration message: 

3> If the UE needs the SEN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SEN of the target cell; 

3> else: 

4> apply the new PUCCH and Sounding RS configuration; 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 311 ETSI TS 136 523-1 V8.0.1 (2009-01) 

2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 
2> the procedure ends. 

[TS 36.331, clause 5.3.5.6] 

The UE shall: 

1> If T304 expires (handover failure): 

NOTE 1 Following T304 expiry dedicated preambles, if provided within the rach-ConfigDedicated, are not 
available for use by the UE anymore. 

2> revert back to the configuration used in the source cell, excluding the physical layer configuration; 

NOTE 2: The UE reverts to the RRC configuration as well as the layer 2 configuration (PDCP/RLC/MAC) used in 
the source cell. 

2> initiate the connection re-establishment procedure as specified in 5.3.7, upon which the RRC connection 
reconfiguration procedure ends. 

[TS 36.331, clause 5.3.7.2] 

The UE shall only initiate the procedure when security has been activated. The UE initiates the procedure when one of 
the following conditions is met: 



1> upon handover failure, in accordance with 5.3.5.6; or 

Upon initiation of the procedure, the UE shall: 

1> stop timer T310, if running; 

1> stop timer T312, if running; 

1> start timer T311; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 1: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HEN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> select a suitable cell in accordance with the cell selection process as specified in [4]; 
[TS 36.331, clause 5.3.7.4] 
The UE shall set the contents of RRCConnectionReestablishmentRequest message as follows: 

1> set the IE ue-Identity as follows: 

2> set the c-RNTI to the C-RNTI used in the source cell (handover failure case) or used in the cell in which the 
trigger for the re-establishment occurred (other cases); 

2> set the cellldentity to the Physical layer identity of the source cell (handover failure case) or of the cell in 
which the trigger for the re-establishment occurred (other cases); 

2> set the shortMAC-I io the 16 least significant bits of the MAC -I calculated: 
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3> over the concatenation of the ASN. 1 encoded Cellldentity of the current cell, PhysicalCellldentity of the 
cell the UE was connected to prior to the failure and C-RNTI that the UE had in the cell it was connected 
to prior to the failure; 

3> with the integrity protection key and integrity protection algorithm that was used in the cell the UE was 
connected to prior to the failure; and 

3> with all input bits for COUNT, BEARER and DIRECTION set to binary ones. 

2> else if the re-establishment procedure was initiated due to handover failure as specified in 5.3.5.6 (intra-LTE 
handover failure) or 5.4.3.5 (inter-RAT mobility from EUTRA failure): 

3> set the reestablishmentCause to the value 'handoverFailure' ; 

1> set the IE reestablishmentCause as follows: 



The UE shall submit the RRCConnectionReestablishmentRequest message to lower layers for transmission. 
[TS 36.331, clause 5.3.7.5] 

NOTE: Prior to this, lower layers allocate a C-RNTI. For further details see TS 36.321 [6]; 
The UE shall: 

1> Stop timer T301; 

1> resume SRBl after reconfiguring it in accordance with the received radioResourceConfiguration and as 
specified in 5.3.10; 

1> configure lower layers to re-activate integrity protection using the previously configured algorithm immediately, 
i.e. integrity protection shall be applied to all subsequent messages received and sent by the UE, including the 
message used to indicate the successful completion of the procedure; 

1> configure lower layers to apply ciphering using the previously configured algorithm immediately, i.e. ciphering 
shall be applied to all subsequent messages received and sent by the UE, including the message used to indicate 
the successful completion of the procedure; 

1> send the RRCConnectionReestablishmentComplete message as specified in 5.3.7.6; 

1> Resume the RRC connection with the restriction that the use of all radio bearers other than SRBl is suspended 
until a subsequent RRCConnectionReconfiguration message is received; 

[TS 36.331, clause 5.3.7.6] 
The UE shall submit the RRCConnectionReestablishmentComplete message to lower layers for transmission. 

[TS 36.331, clause 5.3.10.4] 

The UE shall: 

1> if the received radioResourceConfiguration includes the IE MAC-MainConfiguration: 

2> if the current UE configuration does not include a DL-SCH transport channel configuration (DL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit': 

4> establish an DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 
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3> if the transportChannelConfig is set to 'explicit': 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the DL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

2> if the current UE configuration does not include a UL-SCH transport channel configuration (UL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit' 

4> establish an UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a UL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit' 

4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.5] 

The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> if the current UE configuration does not include a physical channel configuration (physical channel 
establishment): 

3> establish the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> else: 

3> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

1> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

1> if the received RRCConnectionReconfiguration message includes the mobilityControlInformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 

8.2.4.7.3 Test description 

8.2.4.7.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 
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UE: 

None. 

Preamble: 

The UE is in state Generic RB Established (state 3) on cell 1 according to [18]. 



8.2.4.7.3.2 



Test procedure sequence 



Table 8.2.4.7.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
and "T2" are to be applied subsequently. The exact instants on which these values shall be applied are described in the 
texts in this clause. 

Table 8.2.4.7.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that 
measurement results for Cell 1 (Ml) and 
Cell 2 (M2) satisfy exit condition for event 
A3(M2 + Hys<M1). 


T1 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be such that 
measurement results for Cell 1 (M1) and 
Cell 2 (M2) satisfy entry condition for event 
A3(M2-Hys>M1). 


T2 


Ro 


dBm 


P21 (FFS) 


P22 (FFS) 


P21 and P22 shall be assigned values to 
satisfy SrxlevCell 1 > SrxlevCell 2 and 
SrxlevCell 2 < such that selecting Cell 1 
is guaranteed 
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Table 8.2.4.7.3.2-2: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra frequency measurement. 


<- 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


-> 


RRCConnectionReconfigurationC 
ompiete 






3 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T1 " in table 8.2.4.7.3.2-1 . 


- 


- 


- 


- 


4 


The UE transmits a MeasurementReport 
message to report event A3 with the measured 
RSRP value for Cell 2. 


-> 


MeasurementReport 






5 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2. 


<- 


RRCConnectionReconfiguration 








EXCEPTION: In parallel to the events 
described in step 6 the steps specified in Table 
8.2.4.7.3.2-3 should take place. 










6 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T2" in table 8.2.4.7.3.2-1 . 


- 


- 


1 




7 


Check: Does the UE transmit an 
RRCConnectionReestabiislimentRequest 
message on Cell 1? 


-> 


RRCConnectionReestablisiiment 
Request 


1 


P 


8 


The SS transmits an 

RRCConnectionReestabiistiment message to 
resume SRB1 operation and re-activate 
security. 


<- 


RRCConnectionReestablisiiment 


1 




9 


Check: Does the UE transmit an 

RRCConnectionReestabiislimentComplete 

message? 


-> 


RRCConnectionReestablisiiment 
Compiete 


1 


P 


10 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 1 ? 






1 




Table 8.2.4.7.3.2-2: Parallel behaviour 


St 


Procedure 


IMessage Sequence 


TP 


Verdict 


U-S 


lUlessage 




EXCEPTION: The steps 1 and 2 below are 
repeated for the duration of T304 


- 


- 


- 


- 


1 


The UE attempts to perform the intra 
frequency handover using IVIAC Random 
Access Preamble on Cell 2 










2 


The SS does not respond. 


- 


- 


- 


- 
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8.2.4.7.3.3 



Specific message contents 



Table 8.2.4.7.3.3-1 RRCConnectionReconfiguration (step 1 , Table 8.2.4.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration SEOUENCE { 








measObjectToRemoveList 


Not present 






measObjectToAddlVlodifyList SEOUENCE 
(SIZE (1 ..maxObjectId)) OF SEOUENCE { 


1 entry 






measObjectld[1] 


IdlVleasQbjectEUTRA- 
M01 






measObject[1] CHOICE! 








measObjectEUTRA 


MeasObjectEUTRA-M01 






} 








} 








reportConfigToRemoveList 


Not present 






reportConfigToAddModifyList SEQUENCE 
(SIZE (L.maxReportConfigld)) OF SEQUENCE { 


1 entry 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






reportConfig[1] CHOICE! 








reportConfigEUTRA 


ReportConfigEUTRA- 
RC1 






1 








} 








measldloRemoveList 


Not present 






measldloAddModifyLlst SEQUENCE (SIZE 
(L.maxMeasId)) OF SEQUENCE { 


1 entry 






measld[1] 


1 






measObjectld[1] 


IdlVleasObjectEUTRA- 
M01 






reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






1 








quantityConfig 


FFS 






measGapConfig 


Not present 






s-l\/leasure 


Not present 






hrpd-PreRegistrationlnfo 


Not present 






mbsfn-NeighbourCellConfig 


Not present 






speedDependentParameters 


Not present 






} 








radioResourceConfiguration 


Not present 






} 








1 








} 








} 
















MeasObjectEUTRA ::= SEQUENCE { 


MeasQbjectEUTRA-MQ1 






eutra-Carrierlnfo SEOUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 2 






} 








measurementBandwidth 


Not present 






offsetFreq 


dBO 






cellsToRemoveList 


Not present 






cellsToAddModifyList 


Not present 






blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyLlst 


Not present 






cellForWhichToReportCGI 


Not present 






} 
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ReportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 






triggerType CHOICE { 








event SEQUENCE { 








eventid CHQICE { 








eventAS SEQUENCE { 








a3-0ffset 


FFS 






} 








1 








hysteresis 


FFS 






timeToTrigger 


FFS 






} 








} 








triggerQuantity 


rsrp 






reportQuantity 


sameAsTriqqerOuantity 






maxReportCells 


8 






reportlnterval 


Not present 






reportAmount 


Not present 














} 
















Table 8.2.4.7.3.3-2 MeasurementReport (step 4, Table 8.2.4.7.3.2-2) 


Derivation Path: 36.508, Table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


IVIeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-r8 SEQUENCE { 








measuredResults SEQUENCE { 








measid 


1 






measResultServing 


FFS 






mobilitylVleasResults CHOICE { 








measResultListEUTRA SEQUENCE (SIZE 
(1 ..maxCellReport)) OF SEQUENCE { 


1 entry 






physicalCellldentity[1] 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






globalCellldentity[1] 


Not present 






measResultEUTRA[1l SEQUENCE { 








rsrpResult 


FFS 






rsrqResult 


Not present 














} 








1 








} 








} 








} 








} 








1 








} 
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Table 8.2.4.7.3.3-3 RRCConnectionReconfiguration (step 5, Table 8.2.4.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-6, condition RBC-HO | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HQ 






targetCellldentity 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






eutra-CarrierFreq 


Not present 






} 








securityConfiguration 


SecurityConfiguration-HQ 






ue-Relatedlnformation 


UE-Relatedlnformation- 
HO 






} 








1 








1 








} 









Table 8.2.4.7.3.3-4 RRCConnectionReestablishmentRequest (step 7, Table 8.2.4.7.3.2-2) 



Derivation Path: 36.508, Table 4.6.1-12 | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReestablishmentRequest ::= 
SEQUENCE! 








criticalExtensions CHOICE { 








rrcConnectionReestablishmentRequest-r8 
SEQUENCE! 








reestablishmentCause 


handoverFailure 






} 








} 








} 









8.2.4.8 RRC Connection Reconfiguration / Handover: Failure (re-establishment 

failure) 



Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.2.4.8.1 



Test Purpose (TP) 



(1) 

with { UE having completed the radio bearer establishment and initial security activation procedure 
and after receiving an RRCConnectionReconfiguration message including an IE 

mobilityControllnformation indicating a different E-UTRA cell having attempted intra frequency 
handover } 
ensure that { 

when { UE detects handover failure and fails an RRC connection re-establishment procedure } 
then { UE enters the E-UTRA RRC_IDLE state } 



8.2.4.8.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4, 
5.3.5.6, 5.3.7.2, 5.3.7.3, 5.3.7.4, 5.3.7.7 and 5.3.12. 

[TS 36.331, clause 5.3.5.4] 
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If the RRCConnectionReconfiguration message includes the mobilityControlInformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304 with the timer value set to t304, as included in the mobilityControlInformation; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HFN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTI to the value of the newUE-Identity; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> If ihQ RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 
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1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the physicalConfigDedicated is included in the RRCConnectionReconfiguration message: 

3> If the UE needs the SFN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SFN of the target cell; 

3> else: 

4> apply the new PUCCH and Sounding RS configuration; 

2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 

2> the procedure ends. 

[TS 36.331, clause 5.3.5.6] 

The UE shall: 

1> If T304 expires (handover failure): 

NOTE 1: Following T304 expiry dedicated preambles, if provided within the rach-ConfigDedicated, are not 
available for use by the UE anymore. 

2> revert back to the configuration used in the source cell, excluding the physical layer configuration; 

NOTE 2: The UE reverts to the RRC configuration as well as the layer 2 configuration (PDCP/RLC/MAC) used in 
the source cell. 

2> initiate the connection re-establishment procedure as specified in 5.3.7, upon which the RRC connection 
reconfiguration procedure ends. 

[TS 36.331, clause 5.3.7.2] 

The UE shall only initiate the procedure when security has been activated. The UE initiates the procedure when one of 
the following conditions is met: 

1> upon handover failure, in accordance with 5.3.5.6; or 

Upon initiation of the procedure, the UE shall: 

1> start timer T3 11; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 1 : The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of the SN and 
the HEN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> select a suitable cell in accordance with the cell selection process as specified in [4]; 

[TS 36.331, clause 5.3.7.3] 
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2> initiate transmission of the RRCConnectionReestablishmentRequest message in accordance with 5.3.7.4; 

[TS 36.331, clause 5.3.7.4] 

The UE shall set the contents of RRCConnectionReestablishmentRequest message as follows: 

1> set the IE ue-Identity as follows: 

2> set the c-RNTI to the C-RNTI used in the source cell (handover failure case) or used in the cell in which the 
trigger for the re-establishment occurred (other cases); 

2> set the cellldentity to the Physical layer identity of the source cell (handover failure case) or of the cell in 
which the trigger for the re-establishment occurred (other cases); 

2> set the shortMAC-I to the 16 least significant bits of the MAC-1 calculated: 

3> over the concatenation of the ASN.l encoded Cellldentity of the current cell, PhysicalCellldentity of the 
cell the UE was connected to prior to the failure and C-RNTI that the UE had in the cell it was connected 
to prior to the failure; 

3> with the integrity protection key and integrity protection algorithm that was used in the cell the UE was 
connected to prior to the failure; and 

3> with all input bits for COUNT, BEARER and DIRECTION set to binary ones. 

1> set the IE reestablishmentCause as follows: 



2> else if the re-establishment procedure was initiated due to handover failure as specified in 5.3.5.6 (intra-LTE 
handover failure) or 5.4.3.5 (inter-RAT mobility from EUTRA failure): 

3> set the reestablishmentCause to the value 'handoverFailure' ; 



The UE shall submit the RRCConnectionReestablishmentRequest message to lower layers for transmission. 
[TS 36.331, clause 5.3.7.7] 
Upon T3 1 1 expiry, the UE shall: 

1> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 

[TS 36.331, clause 5.3.12] 

Upon moving from RRC_CONNECTED to RRCJDLE, the UE shall: 
1> reset MAC and re-establish RLC for all RBs that are established; 

1> stop all timers that are running except T320; 

1> release all radio resources, including release of the RLC entity and the associated PDCP entity for all established 
RBs; 

1> indicate the release of the RRC connection to upper layers; 

1> enter RRC IDLE. 
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8.2.4.8.3 

8.2.4.8.3.1 

System Simulator: 
- Cell 1 and Cell 2 



Test description 
Pre-test conditions 



UE: 



None 



Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 



8.2.4.8.3.2 



Test procedure sequence 



Table 8.2.4.8.3.2-1 illustrates the downlink power levels and other changing parameters to be applied for the cells at 
various time instants of the test execution. Row marked "TO" denotes the initial conditions, while columns marked "Tl" 
and "T2" are to be applied subsequently. The exact instants on which these values shall be applied are described in the 
texts in this clause. 

Table 8.2.4.8.3.2-1 : Time instances of cell power level and parameter changes 





Parameter 


Unit 


Celll 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that measurement results for 
Cell 1 (M1) and Cell 2 (M2) satisfy exit condition for event 
A3(/W2+Hys<M1). 


Tl 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be such that measurement results for 
Cell 1 {M1) and Cell 2 (M2) satisfy entry condition for event 
A3(M2-Hys>M1). 


T2 


Ro 


dBm 


P21 (FFS) 


P22 (FFS) 


P21 and P22 shall be assigned values to satisfy Srxlevceii i 
> Srxlevceii 2 and Srxlevceii 2 <0 such that selecting Cell 1 is 
guaranteed 
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Table 8.2.4.8.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra frequency measurement. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
ompiete 






3 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T1 " in table 8.2.4.8.3.2-1 . 


- 


- 


- 


- 


4 


The UE transmits a MeasurementReport 
message to report event A3 with the measured 
RSRP value for Cell 2. 


— > 


MeasurementReport 






5 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform intra frequency 
handover to Cell 2. 


<— 


RRCConnectionReconfiguration 








EXCEPTION: In parallel to the events 
described in step 6 the steps specified in Table 
8.2.4.8.3.2-3 should take place. 










6 


The SS changes Cell 1 and Cell 2 parameters 
according to the row "T2" in table 8.2.4.8.3.2-1 . 


- 


- 


- 


- 


7 


Check: Does the UE transmit an 
RRCConnectionReestablislimentRequest 
message on Cell 1? 


— > 


RRCConnectionReestablisiiment 
Request 


1 


P 


8 


The SS does not respond to any 
RRCConnectionReestablislimentRequest 
message and waits for [X]s to ensure that 
T311 expires. 






1 




9 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC IDLE state on Cell 1? 






1 




Table 8.2.4.8.3.2-3: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 




EXCEPTION: The steps 1 and 2 below are 
repeated for the duration of T304 


- 


- 


- 


- 


1 


The UE attempts to perform the intra 
frequency handover using MAC Random 
Access Preamble on Cell 2 










2 


The SS does not respond. 


- 


- 


- 


- 



8.2.4.8.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.2.4.8.3.3-1 : RRCConnectionReconfiguration (step 1 , Table 8.2.4.8.3.2-2) 



Derivation path: 36.508 table 4.6.1-6 



Information Element 



Value/Remark 



Comment 



Condition 



RRCConnectionReconfiguration ::= SEQUENCE { 
criticalExtensions CHOICE { 
c1 CHOICE! 
rrcConnectionReconfiguration-r8 SEOUENCE { 
measurementConfiguration SEOUENCE { 
measObjectToRemoveList 
measObjectToAddlVlodifyList SEOUENCE 
(SIZE (1 ..maxObjectId)) OF SEOUENCE { 
measObjectld[1] 

measObject[1] CHOICE { 
measObjectEUTRA 
} 
} 

reportConfigToRemoveList 
reportConfigToAddlVlodifyList SEQUENCE 
(SIZE (L.maxReportConfigld)) OF SEOUENCE { 
reportConfigld[1] 

reportConfig[1] CHOICE! 
reportConfigEUTRA 



} 
} 

measldToRemoveList 

measldToAddModifyList SEOUENCE (SIZE 
.maxMeasId)) OF SEQUENCE { 

nneasld[1] 

measObjectld[1] 

reportConfigld[1] 

} 

quantityConfig 

measGapConfig 

s-Measure 

hrpd-PreRegistrationlnfo 

mbsfn-NeighbourCellConfig 

speed DependentParameters 



} 



} 
radioResourceConfiguration 



} 



MeasObjectEUTRA ::= SEQUENCE ■ 
eutra-Carrierlnfo SEOUENCE { 
earfcn-DL 

} 

measurementBandwidth 

offsetFreq 

cellsToRemoveLlst 

cellsToAddModifyList 

blackListedCellsToRemoveList 

blackListedCellsToAddModifyLlst 

cellForWhichToReportCGI 



} 



ReportConfigEUTRA ::= SEQUENCE { 

triggerType CHOICE { 
event SEOUENCE { 



Not present 
1 entry 

IdlVleasObjectEUTRA- 
M01 

MeasObjectEUTRA-M01 



Not present 
1 entry 

IdReportConfJgEUTRA- 
RC1 

ReportConfigEUTRA- 
RC1 



Not present 
1 entry 

1 

IdlVleasObjectEUTRA- 

M01 

IdReportConfigEUTRA- 

RC1 

FFS 

Not present 
Not present 
Not present 
Not present 
Not present 

Not present 



MeasObjectEUTRA-MOl 

Same downlink EARFCN 
as used for Cell 2 

Not present 
dBO 

Not present 
Not present 
Not present 
Not present 
Not present 



ReportConfigEUTRA- 
RC1 
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eventid CHOICE { 
eventAS SEQUENCE { 
a3-0ffset 
} 


FFS 






} 

hysteresis 
timeToTrigger 
} 


FFS 
FFS 






} 

triggerQuantity 

reportQuantity 

maxReportCells 

reportlnterval 

reportAmount 


rsrp 

sameAsTriggerQuantity 

8 

Not present 

Not present 







Table 8.2.4.8.3.3-2: MeasurementReport {step 4, Table 8.2.4.8.3.2-2) 



Derivation path: 36.508 table 4.6.1-3 


Information Element 


Value/Remark 


Comment 


Condition 


MeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-r8 SEQUENCE { 








measuredResults SEQUENCE { 








measid 


1 






measResultServing 


FFS 






mobilitylVleasResults CHOICE { 








measResultListEUTRA SEQUENCE (SIZE 


1 entry 






(1..maxCellReport)) OF SEQUENCE { 








physicalCellldentity[1] 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






globalCellldentity[1] 


Not present 






measResultEUTRA[1] SEQUENCE { 








rsrpResult 


FFS 






rsrqResult 

}'" 

} 
} 
} 
} 
} 
} 
} 


Not present 
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Table 8.2.4.8.3.3-3: RRCConnectionReconfiguration (step 5, Table 8.2.4.8.3.2-2) 



Derivation path: 36.508 table 4.6.1-6, condition RBC-HO | 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HQ 






targetCellldentity 


PhysicalCellldentity of 
Cell 2 (see 36.508 clause 
4.4.4.2) 






eutra-CarrierFreq 
1 


Not present 






securityConfiguration 


SecurityConfiguration-HO 






ue-Relatedlnformation 


UE-Relatedlnformation- 






} 
} 
} 
} 


HO 







Table 8.2.4.8.3.3-5: RRCConnectionReestablishmentRequest (step 7, Table 8.2.4.8.3.2-2) 



Derivation path: 36.508 table 4.6.1-12 | 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReestablishmentRequest ::= 
SEQUENCE! 
criticalExtensions CHOICE { 
rrcConnectionReestablishmentRequest-r8 
SEQUENCE! 

reestablishmentCause 
} 
} 
} 


handoverFailure 







8.2.4.9 RRC Connection Reconfiguration / Handover (Inter band blind handover): 

Success 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41. 



8.2.4.9.1 



Test Purpose (TP) 



(1) 

with { UE having completed the radio bearer establishment and initial security activation procedure 
and performed the inter frequency measurement} 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControllnformation indicating an E-UTRA frequency on different frequency band } 
then { UE transmits an RRCConnectionReconfigurationComplete message } 



8.2.4.9.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clauses 5.3.5.4, 
5.3.10.4 and 5.3.10.5. 

[TS 36.331, clause 5.3.5.4] 
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If the RRCConnectionReconfiguration message includes the mobilityControlInformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304 with the timer value set to t304, as included in the mobilityControlInformation; 

1> request PDCP to initiate the PDCP Re-establishment procedure for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of the L2 re-establishment, e.g. the re- 
transmission of unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of 
the SN and the HFN, is specified in [8]. 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTI to the value of the newUE-Identity; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 

1> If ihe RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm, i.e. the indicated integrity 

protection configuration shall be applied to all subsequent messages received and sent by the UE in the target 
cell, including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm, i.e. the indicated ciphering configuration 
shall be applied to all subsequent messages received and sent by the UE in the target cell, including the 
message used to indicate the successful completion of the procedure; 

1> \f ihe RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> synchronise to the DL of the target cell; 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 328 ETSI TS 136 523-1 V8.0.1 (2009-01) 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the physicalConfigDedicated is included in the RRCConnectionReconfiguration message : 

3> If the UE needs the SFN of the target cell to apply the PUCCH and Sounding RS configuration: 

4> apply the new PUCCH and Sounding RS configuration upon acquiring the SFN of the target cell; 

3> else: 

4> apply the new PUCCH and Sounding RS configuration; 

2> indicate to PDCP to complete the PDCP Re-establishment procedure for all DRBs that are established, if any; 

2> the procedure ends. 

[TS 36.331, clause 5.3.10.4] 

The UE shall: 

1> if the received radioResourceConfiguration includes the IE MAC-MainConfiguration: 

2> if the current UE configuration does not include a DL-SCH transport channel configuration (DL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit': 

4> establish an DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a DL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit': 

4> reconfigure the DL-SCH transport channel in accordance with the received dl-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the DL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

2> if the current UE configuration does not include a UL-SCH transport channel configuration (UL-SCH 
establishment): 

3> if the transportChannelConfig is set to 'explicit' 

4> establish an UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> establish a UL-SCH transport channel in accordance with the default configuration for SRBl as 
specified in 9.2.1.1; 

2> else: 

3> if the transportChannelConfig is set to 'explicit' 
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4> reconfigure the UL-SCH transport channel in accordance with the received ul-SCH-Configuration; 

3> else if the transportChannelConfig is set to 'default': 

4> reconfigure the UL-SCH transport channel in accordance with the default configuration for SRB 1 as 
specified in 9.2.1.1; 

[TS 36.331, clause 5.3.10.5] 

The UE shall: 

1> if the received radioResourceConfiguration includes the physicalConfigDedicated: 

2> if the current UE configuration does not include a physical channel configuration (physical channel 
establishment): 

3> establish the physical channel configuration in accordance with the received physicalConfigDedicated; 

2> else: 

3> reconfigure the physical channel configuration in accordance with the received physicalConfigDedicated; 

1> apply the default configuration applicable for the antennalnformation as specified in 9.2.3, until explicitly 
receiving a configuration; 

1> if the received RRCConnectionReconfiguration message includes the mobility Controllnformation: 

2> if SPS resource is activated: 

3> deactivate SPS resource; 



8.2.4.9.3 
8.2.4.9.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 and Cell 10 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) on cell 1 according to [18]. 



8.2.4.9.3.2 



Test procedure sequence 



Table 8.2.4.9.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
order the UE to perform inter band handover to 
Cell 10. 


<— 


RRCConnectionReconfiguration 






2 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message on Cell 10? 


-> 


RRCConnectionReconfigurationC 
omplete 


1 


P 


3 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 10? 






1 
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8.2.4.9.3.3 Specific message contents 

Table 8.2.4.9.3.3-1 : RRCConnectionReconfiguration (step 1, Table 8.2.4.9.3.2-1) 



Derivation Path: 36.508, Table 4.6.1-6, condition RBC-HO | 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








mobilityControllnformation SEQUENCE { 


MobilityControllnformatio 
n-HQ 






targetCellldentity 


PhysicalCellldentity of 
Cell 10 (see 36.508 
clause 4.4.4.10) 






eutra-CarrierFreq SEQUENCE { 








earfcn-DL 


Same downlink EARFCN 
as used for Cell 10 






earfcn-UL 


Not present 






} 








} 








securityConfiguration 


SecurityConfiguration-HQ 






ue-Relatedlnformation 


UE-Relatedlnformation- 
HO 






} 








} 








} 








} 









8.3 Measurement Configuration Control and Reporting 
8.3.1 Intra E-UTRAN measurements 

8.3.1 .1 Measurement configuration control and reporting / intra E-UTRAN 

measurements: event A1 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41 + R2-08597 



8.8.3.1.1.1 



(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state and measurement configured for event Al with event based 
periodical reporting } 
ensure that { 

when { Serving cell becomes better than absolute threshold plus hysteresis } 
then { UE sends MeasurementReport message at regular intervals while entering conditions for 
event Al are satisfied } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state and periodical meausurement reporting triggered by event Al 

ongoing} 

ensure that { 

when { Serving cell becomes worse than absolute threshold minus hysteresis } 
then { UE stops sending MeasurementReport message } 



8.3.1.1.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.4.1, 5.5.4.2 and 5.5.5. 
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[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobility Controllnformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> \i ihQ RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measldList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of frequencies 
(GERAN) to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
HackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 



2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration while the VarMeasurementReports does not include an entry 
for this measid (a first cell triggers the event): 

3> include an entry within the VarMeasurementReports for this measid; 

3> set the numberOfReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReportsfor this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells not included in the cellsTriggeredList for a duration exceeding the 
value of timeToTrigger defined for this event within the VarMeasurementConfiguration (a subsequent cell 
triggers the event): 

3> set the numberOfReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'event' and if the leaving condition applicable for this event is fulfilled for one or 
more of the cells included in the cellsToReportList defined within the VarMeasurementReportsfor this 
measldf or a duration exceeding the value of timeToTrigger defined within the 
VarMeasurementConfiguration for this event: 
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3> remove the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReportsfox this 
measid; 

3> if the cellsTriggeredList defined within the VarMeasurementReports for this measid is empty: 

4> remove the entry within the VarMeasurementReports for this measid; 

4> stop the periodical reporting timer for this event, if running; 

[TS 36.331, clause 5.5.4.2] 

The UE shall: 

1> apply inequalityAl-1, as specified below, as the entry condition for this event; 

1> apply inequalityAl-2, as specified below, as the leaving condition for this event; 

InequalityAl-1 (Entering condition) 

Ms — Hys > Thresh 

InequalityAl-2 (Leaving condition) 

Ms + Hys < Thresh 

The variables in the formula are defined as follows: 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Thresh is the threshold parameter for this event (i.e. al-Threshold as defined within the 
VarMeasurementConfiguration for this event) 

Ms is expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Hys is expressed in dB 

Thresh is expressed in dBm in case Ms is expressed in dBm; otherwise it is expressed in dB 

[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> if the triggerType is set to 'event': 

2> set the neighbouringMeasResultsto include all cells included in the cellsTriggeredList as defined within the 
VarMeasurementReportsfor this measid 

1> ordered as follows: 

2> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, as follows: 

3> If for E-UTRA the reportQuantity is set as 'both' : 
4> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 

3> else: 
4> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 
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1> increment the numberOfReportsSent as defined within the VarMeasurementReportsfor this measldby 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than to 
reportAmount as defined within the reporting configuration for this event as defined in variable 
VarMeasurementConfiguration: 

2> stop the periodical reporting timer, if running; 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 

1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 



8.3.1.1.3 
8.3.1.1.3.1 



Test description 
Pre-test conditions 



System Simulator: 
- Cell 1 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.3.1.1.3.2 



Test procedure sequence 



Table 8.3.1.1.3.2-1 illustrates the downlink power levels to be applied for Cell 1 at various time instants of the test 
execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl", "T2", "T3" and "T4" are to be 
applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 

Table 8.3.1.1.3.2-1 : Power levels 





Parameter 


Unit 


Celll 


Remark 


TO 






[-95] 


Power level is such that Ms + Hys < Thresh 


Tl 






[-65] 


Power level is such that Ms > Thresh and Ms - 
Hys < Thresh 


T2 


Cell-specific RS 
EPRE 


dBm 


[-44] 


Power level is such that entry condition for event 
A1 is satisfied Ms - Hys > Thresh 


T3 






[-80] 


Power level is such that Ms < Thresh and Ms + 
Hys > Thresh 


T4 






[-95] 




Note: The total tolerance used is the sum of downlink signal level uncertainty (TS 36.508 clause 4.3.4.1 ) and 
absolute UE measurement accuracy (TS 36.133 clause 9). 
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Table 8.3.1.1.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LIE measurement and reporting for event 
A1. 


<- 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


SS re-adjusts the cell-specific reference signal 
level according to row "T1" in table 
8.3.1.1.3.2.-1. 










4 


Check: does the UE transmit a 
MeasurementReport message within the next 
10s? 




MeasurementReport 


1 


F 


5 


SS re-adjusts the cell-specific reference signal 
level according to row "T2" in table 
8.3.1.1.3.2.-1. 










6 


Check: does the UE transmit a 
MeasurementReport message to report event 
A1 with the measured RSRP value for Cell 1? 


-> 


MeasurementReport 


1 


P 




EXCEPTION: Step 7 below is repeated until 3 
MeasurementReport messages are received 
from the UE 










7 


Check: does the UE transmit a 
MeasurementReport message, with a 
measured RSRP value for Cell 1 ? 


— > 


MeasurementReport 


1 


P 


8 


SS re-adjusts the cell-specific reference signal 
level according to row "T3" in table 
8.3.1.1.3.2.-1. 












EXCEPTION: Step 9 below is repeated until 3 
MeasurementReport messages are received 
from the UE 










9 


Check: does the UE transmit a 
MeasurementReport message, with a 
measured RSRP value for Cell 1 ? 


— > 


MeasurementReport 


1,2 


P 


10 


SS re-adjusts the cell-specific reference signal 
level according to row "T4" in table 
8.3.1.1.3.2.-1. 










11 


Check: does the UE attempt to transmit an 
uplink message within the next 10s? 


- 


- 


2 


F 



Editors note: It is FFS if tight enough test tolerances can be achieved to perform test steps 4 and 9 

8.3.1 .1 .3.3 Specific message contents 

Table 8.3.1 .1 .3.3-1 RRCConnectionReconfiguration (step 1 , Table 8.3.1 .1 .3.2-2) 

Derivation Path: 36.508 clause 4.6.1 table 4.6.1-8 with condition Measurement 
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Table 8.3.1 .1 .3.3-2 MeasurementConfiguration (step 1 , Table 8.3.1 .1 .3.2-2) 



Derivation path: 36.508 clause 4.6.6 table 4.6.6-1 | 


Information Element 


Value/Remark 


Comment 


Condition 


measurementConfiguration ::= SEQUENCE { 

measObjectToAddModifyUst SEQUENCE (SIZE 
(1 ..maxQbjectId)) QF SEQUENCE { 

measQbjectld[1] 

measQbject[1 ] 

} 

reportConfigToAddModifyList SEQUENCE (SIZE 
(L.tnaxReportConfigld)) QF SEQUENCE { 

reportConfigld[1] 

reportConfig[1] 

} 

measldToAddModifyLlst SEQUENCE (SIZE 
(1 ..maxMeasId)) OF SEQUENCE { 
measld[1] 
measQbjectld[1] 
reportConfigld[1] 
} 
} 


1 entry 

ldMeasQbject-f1 

MeasObjectEUTRA- 

GENERIC(fl) 

1 entry 

IdReportConfig-AI 
ReportConfig-AI-H 

1 entry 

1 

ldMeasQbject-f1 

ldReportConfig-A1 







Table 8.3.1 .1 .3.3-3 ReportConfig-AI-H (step 1 , Table 8.3.1 .1 .3.3-2) 



Derivation path: 36.508 clause 4.6.6 table 4.6.6-4 ReportConfigEUTRA-AI ([-72]) | 


Information Element 


Value/Remark 


Comment 


Condition 


ReportConfigEUTRA ::= SEQUENCE { 
triggerType CHQICE { 
event SEQUENCE { 

hysteresis 
} 
} 
} 


[30] 


15dB 





Table 8.3.1.1.3.3-4 MeasurementReport (steps 6, 7 and 9, Table 8.3.1.1.3.2-2) 



Derivation path: 36.508 4.6.1 table 4.6.1-5 | 


Information Element 


Value/Remark 


Comment 


Condition 


IVIeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-rS SEQUENCE { 








measuredResults ::= SEQUENCE { 








measid 


1 






measResultServing ::= SEQUENCE { 




Report Cell 1 




rsrpResult 


(0 .. 96) 


Measured RSRP 
result 




rsrq Result 


Not present 






1 

neighbouringMeasResults CHQICE {} 

} 
} 
} 
} 
1 


Not present 







8.3.1 .2 Measurement configuration control and reporting / intra E-UTRAN 

measurements: event A2 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RAN#41 + R2-08597 
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8.8.3.1 .2.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_CONNECTED state and measurement configured for event A2 with event based 
periodical reporting } 
ensure that { 

when { Serving cell becomes worse than absolute threshold minus hysteresis } 
then { UE sends MeasurementReport message at regular intervals while entering conditions for 
event A2 are satisfied } 



(2) 

with { UE in E-UTRA RRC_CONNECTED state and periodical meausurement reporting triggered by event A2 

ongoing} 

ensure that { 

when { Serving cell becomes better than absolute threshold plus hysteresis } 
then { UE stops sending MeasurementReport message } 
} 

8.3.1.2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.4.1, 5.5.4.3 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> \i ihQ RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measldList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of frequencies 
(GERAN) to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
HackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 



2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration while the VarMeasurementReports does not include an entry 
for this measid (a first cell triggers the event): 

3> include an entry within the VarMeasurementReports for this measid; 

3> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for 
this measid, if not included; 
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3> initiate the measurement reporting procedure, as specified in 5.5.5; 



2> if the triggerType is set to 'event' and if the entry condition apphcable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells not included in the cellsTriggeredList for a duration exceeding the 
value of timeToTrigger defined for this event within the VarMeasurementConfiguration (a subsequent cell 
triggers the event): 

3> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for 
this measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'event' and if the leaving condition applicable for this event is fulfilled for one or 
more of the cells included in the cellsTriggeredList defined within the VarMeasurementReports for this 
measid for a duration exceeding the value of timeToTrigger defined within the 
VarMeasurementConfiguration for this event: 

3> remove the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for 
this measid; 

3> if the cellsTriggeredList defined within the VarMeasurementReports for this measid is empty: 

4> remove the entry within the VarMeasurementReports for this measid; 

4> stop the periodical reporting timer for this event, if running; 

[TS 36.331, clause 5.5.4.3] 

The UE shall: 

1> apply inequalityA2-l, as specified below, as the entry condition for this event; 

1> apply inequalityA2-2, as specified below, as the leaving condition for this event; 

Inequality A2-1 (Entering condition) 

Ms + Hys < Thresh 

InequalityA2-2 (Leaving condition) 

Ms — Hys > Thresh 

The variables in the formula are defined as follows: 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Thresh is the threshold parameter for this event (i.e. a2-Threshold as defined within the 
VarMeasurementConfiguration for this event) 

Ms is expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Hys is expressed in dB 

Thresh is expressed in dBm in case Ms is expressed in dBm; otherwise it is expressed in dB 

[TS 36.331, clause 5.5.5] 
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For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> if the triggerType is set to 'event': 

2> set the neighbouringMeasResults to include all cells included in the cellsTriggeredList as defined within the 
VarMeasurementReports for this measid 



1> ordered as follows: 

2> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, as follows: 

3> If for E-UTRA the reportQuantity is set as 'both' : 
4> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 

3> else: 

4> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 

1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid hy 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than 
reportAmount as defined within the corresponding reporting configuration as defined in variable 

VarMeasurementConfiguration: 

2> stop the periodical reporting timer, if running; 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 



1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

8.3.1.2.3 Test description 

8.3.1.2.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 

8.3.1 .2.3.2 Test procedure sequence 

Table 8.3.1.2.3.2-1 illustrates the downlink power levels to be applied for Cell 1 at various time instants of the test 
execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl", "T2", "T3" and "T4" are to be 
applied subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 
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Table 8.3.1.2.3.2-1 : Power levels 





Parameter 


Unit 


CelM 


Remarl< 


TO 


Cell-specific RS 
EPRE 


dBm 


[-451 


Power level is such that Ms > Thresh - Hys 


T1 


[-82] 


Power level is such that Ms < Thresh and Ms - 
Hys > Thresh 


T2 


[-95] 


Power level is such that entry condition for event 
A2 is satisfied Ms - Hys < Thres 


13 


[-62] 


Power level is such that Ms > Thresh and Ms + 
Hys < Thresh 


14 


[-45] 




Note: The total tolerance used is the sum of downlink signal level uncertainty (TS 36.508 clause 4.3.4.1 ) and 
absolute UE measurement accuracy (TS 36.133 clause 9). 



Table 8.3.1.2.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LTE measurement and reporting for event 
A2. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmit an 

RCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


SS re-adjusts the cell-specific reference signal 
level according to row "T1 " in table 
8.3.1.2.3.2.-1. 










4 


Check: does the UE transmit a 
MeasurementReport message within the next 
10s? 




MeasurementReport 


1 


F 


5 


SS re-adjusts the cell-specific reference signal 
level according to row "T2" in table 
8.3.1.2.3.2.-1. 










6 


Check: does the UE transmit a 
MeasurementReport message to report event 
A2 with the measured RSRP value for Cell 1 ? 


— > 


MeasurementReport 


1 


P 




EXCEPTION: Step 7 below is repeated until 3 
MeasurementReport messages are received 
from the UE 










7 


Check: does the UE transmit a 
MeasurementReport message, with a 
measured RSRP value for Cell 1 ? 


— > 


MeasurementReport 


1 


P 


8 


SS re-adjusts the cell-specific reference signal 
level according to row "T3" in table 
8.3.1.2.3.2.-1. 












EXCEPTION: Step 9 below is repeated until 3 
MeasurementReport messages are received 
from the UE 










9 


Check: does the UE transmit a 
MeasurementReport message, with a 
measured RSRP value for Cell 1 ? 


— > 


MeasurementReport 


1,2 


P 


10 


SS re-adjusts the cell-specific reference signal 
level according to row "T4" in table 
8.3.1.2.3.2.-1. 










11 


Check: does the UE transmit an 
MeasurementReport message within the next 
10s? 




MeasurementReport 


2 


F 



Editors note; It is FFS if tight enough test tolerances can be achieved to perform test steps 4 and 9. 
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8.3.1 .2.3.3 Specific message contents 

Table 8.3.1.2.3.3-1 RRCConnectionReconfiguration (step 1, table 8.3.1.2.3.2-2) 

Derivation Path: 36.508 clause 4.6.1 table 4.6.1-8 with condition Measurement 

Table 8.3.1.2.3.3-2 MeasurementConfiguration (step 1, Table 8.3.1.2.3.2-2) 



Derivation path: 36.508 clause 4.6.6 table 4.6.6-1 


Information Element 


Value/Remark 


Comment 


Condition 


measurementConfiguration ::= SEQUENCE { 
measObjectToAddModifyList SEQUENCE (SIZE 
(1 ..maxQbjectId)) QF SEQUENCE { 

measQbjectld[1] 

measQbject[1] 

} 

reportConfigToAddModifyList SEQUENCE (SIZE 
(L.tnaxReportConfigld)) QF SEQUENCE { 

reportConfigld[1] 

reportConfig[1] 

} 

measldToAddModifyLlst SEQUENCE (SIZE 
(1 ..maxMeasId)) OF SEQUENCE { 
measld[1] 
measQbjectld[1] 
reportConfigld[1] 
} 
} 


1 entry 

IdMeasQbject-fl 

IVIeasObjectEUTRA- 

GENERIC(fl) 

1 entry 

ldReportConfig-A2 
ReportConfig-A2-H 

1 entry 

1 

IdMeasQbject-fl 

ldReportConfig-A2 







Table 8.3.1.2.3.3-3 ReportConfig-A2-H (step 1, Table 8.3.1.2.3.3-2) 



Derivation path: 36.508 clause 4.6.6 table 4.6.6-5 ReportConfigEUTRA-A2([70]) 


Information Element 


Value/Remark 


Comment 


Condition 


ReportConfigEUTRA ::= SEQUENCE { 
triggerType CHQICE { 
event SEQUENCE { 

hysteresis 
} 
} 
} 


[30] 


15dB 





Table 8.3.1 .2.3.3-4 MeasurementReport (steps 6, 7 and 9, 8.3.1 .2.3.2-2) 



Derivation path: 36.508 table clause 4.6.1 table 4.6.1-5 


Information Element 


Value/Remark 


Comment 


Condition 


MeasurementReport ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








measurementReport-rS SEQUENCE { 








measuredResults ::= SEQUENCE { 








measid 


1 






measResultServing ::= SEQUENCE { 




Report Cell 1 




rsrpResult 


(0 .. 96) 


Measured RSRP 
result 




rsrq Result 


Not present 






nelghbouringMeasResults CHQICE {} 
} 
} 
} 
} 
} 


Not present 
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8.3.1 .3 Measurement configuration control and reporting / intra E-UTRAN 

measurements: 2 simultaneous events A3 (intra and inter frequency 
measurements) 

8.3.1 .3.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state and measurements configured for two event A3 at the same 

time} 

ensure that { 

when { Neighbour becomes offset better than serving } 
then { UE sends MeasurementReport with correct measid for event A3 } 
} 

8.3.1 .3.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.4.1, 5.5.4.4 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> If ihe RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measIdList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of frequencies 
(GERAN) to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
blackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> else consider a neighbouring cell on the associated frequency to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
blackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration or: 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the VarMeasurementReports does not include an entry for this measid: 

4> include an entry within the VarMeasurementReports for this measid; 

4> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 
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3> include the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> if the triggerType is set to 'periodical': 

4> clear the cellsToReportList defined within the VarMeasurementReports for this measid and include 
the applicable cell(s) in the cellsToReportList; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the leaving condition applicable for this event is fulfilled for one or more of the cells included in the 
cellsToReportList defined within the VarMeasurementReports for this measid for a duration exceeding the 
value of timeToTrigger defined within the VarMeasurementConfiguration for this event: 

3> remove the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid; 

[TS 36.331, clause 5.5.4.4] 

The UE shall: 

1> apply inequality A3-1, as specified below, as the entry condition for this event; 

1> apply inequality A3 -2, as specified below, as the leaving condition for this event; 
Inequality A3-1 (Entering condition) 
Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 
Inequality A3-2 (Leaving condition) 
Mn + Ofn + Ocn + Hys <Ms + Ofs + Ocs + Off 
The variables in the formula are defined as follows: 

Mn is the measurement result of the neighbouring cell. 

Ofn is the frequency specific offset of the frequency of the neighbour cell (equals Ofs for intra-frequency 

measurements and is included in MeasObjectEUTRA corresponding to the inter frequency as offsetFreq for 
inter-frequency measurements) 

Ocn is the cell specific offset of the neighbour cell. If not configured zero offset shall be applied (included in 
MeasObjectEUTRA of the serving frequency as parameter celllndividualOffset for intra-f measurements and 
included in MeasObjectEUTRA corresponding to the inter frequency as parameter celllndividualOffset for inter- 
frequency measurements). 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Ofs is the frequency specific offset of the serving frequency (i.e. offsetFreq within the MeasObjectEUTRA 
corresponding to the serving frequency) 

Ocs is the cell specific offset of the serving cell (included in MeasObjectEUTRA of the serving frequency as 
parameter celllndividualOffset) 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Off is the offset parameter for this event (i.e. a3-Offset as defined within the VarMeasurementConfiguration for this 
event) 

Mn, Ms are expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Ofn, Ocn, Ofs, Ocs, Hys, Off are expressed in dB 
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[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> set the mobilityMeasResults to include all cells included in the cellsToReportList as defined within the 
VarMeasurementReports for this measid 

1> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, ordered as follows: 

2> If for E-UTRA the reportQuantity is set as 'both' : 

3> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 
2> else: 

3> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 

Editor's note: It is FFS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 

1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid hy 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than to 
reportAmount as defined within the reporting configuration for this event as defined in variable 
VarMeasurementConfiguration: 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 



1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 

8.3.1.3.3 Test description 

8.3.1.3.3.1 Pre-test conditions 

System Simulator: 

- Celll,Cell2andCell3 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 

8.3.1 .3.3.2 Test procedure sequence 

Table 8.3.1.3.3.2-1 illustrates the downlink power levels to be applied for Cell 1, Cell 2 and Cell 3 at various time 
instants of the test execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl"and "T2" are to 
be applied subsequently. The exact instants on which these values shall be applied are described in the texts in this 
clause. 
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Table 8.3.1.3.3.2-1 : Power levels 





Parameter 


Unit 


Celll 


Cell 2 


Cell 3 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P03 (FFS) 


P01 , P02 and P03 shall be such that entry 

condition for event A3 (measid 1 & 2) is not 

satisfied: 

Mn + Ofn + Ocn + Hys <Ms + Ofs + Ocs + Ojf 


T1 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P13(FFS) 


P1 1 and P12 shall be such that entry condition 
for event A3 (measid 1 ) is satisfied: 

Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 


T2 


Ro 


dBm 


P21 (FFS) 


P22(FFS) 


P23(FFS) 


P21 and P23 shall be such that entry condition 
for event A3 (measid 2) is satisfied: 

Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 



Table 8.3.1.3.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LTE measurement and reporting for two 
event A3 {measid 1 and measid 2) (intra and 
inter frequency measurement). 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


Check: does the UE transmit a 
MeasurementReport message within the next 
10s? 


— > 


MeasurementReport 


1 


F 


4 


SS re-adjusts the cell-specific reference signal 
level according to row "T1" in table 
8.3.1.3.3.2.-1. 










5 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 (measid 1) with the measured RSRP value 
for Cell 2? 


— > 


MeasurementReport 


1 


P 


6 


SS re-adjusts the cell-specific reference signal 
level according to row "T2" in table 
8.3.1.3.3.2.-1. 










7 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 {measid 2) with the measured RSRP value 
for Cell 3? 


— > 


MeasurementReport 


1 


P 


8 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 1? 






1 





Editors note: When test tolerances in TS36.508 will cover measurements steps 4 and 6 above will take them into 
account. 

Editor's note: It is FFS if Cell 3 is included in the MeasurementReport in step 5. 

Editor's note: It is FFS if Cell 2 is included in the MeasurementReport in step 7 



8.3.1.3.3.3 



Specific message contents 



Table 8.3.1.3.3.3-1 : RRCConnectionReconfiguration (step 1) measurementConfiguration test specific 

information elements 

FFS 
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Table 8.3.1.3.3.3-2: MeasurementReport (step 5 ) measuredResults test specific information elements 

FFS 

Table 8.3.1.3.3.3-3: MeasurementReport (step 7 ) measuredResults test specific information elements 

FFS 

8.3.1 .4 Measurement configuration control and reporting / intra E-UTRAN 

measurements: Periodic reporting (intra and inter frequency measurements) 

8.3.1 .4.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state and measurement configured for periodic reporting of intra 
frequency cells and inter frequency cells on specified frequency } 
ensure that { 

when { The UE receives reference signal power for cells on the serving frequency and cells on the 
frequency where measurements are configured } 

then { UE sends MeasurementReport message at regular intervals for these cells } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state and a MeasurementReport message for a configured periodic 
measurement reporting of intra and inter frequency cells was sent } 
ensure that { 

when { A previously reported cell become unavailable or the UE receives reference signal power on 
a reported frequency for a cell which was previously not reported } 

then { UE sends MeasurementReport message at regular intervals for the available intra and inter 
frequency cells } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state and periodic measurement reporting ongoing} 
ensure that { 

when { The UE receives a RRCConnectionReconf iguration message removing measlds for periodic 
reporting } 

then { UE stops sending MeasurementReport messages for these measlds } 
} 

8.3.1 .4.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.2.2,5.5.4.1 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.2.2] 

The UE shall: 

1> for each measid value included in the measIdToRemoveList: 

2> remove the entry, from the parameter measIdList within VarMeasurementConfiguration, with the 
corresponding measid value; 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 346 ETSI TS 136 523-1 V8.0.1 (2009-01) 

2> remove the entry within the VarMeasurementReports for this measid, if included; 

Editors note It has been agreed that the UE should NOT autonomously delete any unused measurement objects or 
reporting configurations. 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measUList within VarMeasurementConfiguration: 



2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the VarMeasurementReports does not include an entry for this measid: 

4> include an entry within the VarMeasurementReports for this measid; 

4> set the numberOfReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> if the triggerType is set to 'periodical': 

4> clear the cellsToReportList defined within the VarMeasurementReports for this measid and include 
the applicable cell(s) in the cellsToReportList; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> set the mobilityMeasResults to include all cells included in the cellsToReportList as defined within the 
VarMeasurementReports for this measid 

1> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, ordered as follows: 

2> If for E-UTRA the reportQuantity is set as 'both' : 

3> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 
2> else: 

3> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 

Editor's note: It is FFS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 

1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid hy 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than to 
reportAmount as defined within the reporting configuration for this event as defined in variable 
VarMeasurementConfiguration: 
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2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 



1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 

Editor's note: It is FFS if, for the case of a SON report of the strongest cell(s) on the carrier, the UE is required to 
report more than one cell. 



8.3.1.4.3 
8.3.1.4.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1, Cell 2, Cell 3, Cell 4 and Cell 6(FFS) 

Editor's Note: It is necessary to add a cell on using frequency f2 to TS 36.508. 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell I. 



8.3.1.4.3.2 



Test procedure sequence 



Table 8.3.1.4.3.2-1 illustrates the downlink power levels to be applied for the cells at various time instants of the test 
execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl" and "T2" are to be applied 
subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 

Table 8.3.1.4.3.2-1 : Power levels 





Parameter 


Unit 


Celll 


Cell 2 


Cell 3 


Cell 4 


Cell 6 


Remark 


TO 






P01 
(FFS) 


P02 

(FFS) 


P03 
(FFS) 


off 


off 


Power levels shall be such that 
camping on Cell 1 is 
guaranteed 


T1 


Ro 


clBm 


P01 
(FFS) 


P02 
(FFS) 


P03 
(FFS) 


P02 
(FFS) 


P03 
(FFS) 




T2 






P01 
(FFS) 


off 


off 


P02 
(FFS) 


P03 
(FFS) 
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Table 8.3.1.4.3.2-2: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LTE measurements and periodical 
reporting for intra and inter frequency cells. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 








EXCEPTION: In parallel to events described in 
steps 3 to 4 the steps specified in table 
8.3.1 .4.3.2.-3 and table 8.3.1 .4.3.2.-4 shall 
take place 










3 


Wait for 30 s to ensure that the UE performs a 
periodical intra frequency reporting and a 
periodical inter frequency reporting. 






1 




4 


SS sets the cell-specific reference signal levels 
and switches Cell 4 and Cell 6 on according to 
row "T1" in table 8.3.1.4.3.2.-1. 










5 


Wait and ignore MeasurementReport 
messages for 5 s to allow for the switching of 
cells. 












EXCEPTION: In parallel to events described in 
steps 6 to 7 the steps specified in table 
8.3.1 .4.3.2.-5 and table 8.3.1 .4.3.2.-6 shall 
take place 










6 


Wait for 30 s to ensure that the UE performs a 
periodical intra frequency reporting and a 
periodical inter frequency reporting. 






1,2 




7 


SS sets the cell-specific reference signal levels 
and switches Cell 2 and Cell 3 off according to 
row "T2" in table 8.3.1 .4.3.2.-1 . 










8 


Wait and ignore MeasurementReport 
messages for 5 s to allow for the switching of 
cells. 












EXCEPTION: In parallel to events described in 
steps 9 to 1 1 the steps specified in table 
8.3.1 .4.3.2.-7 and table 8.3.1 .4.3.2.-8 shall 
take place 










9 


Wait for 30 s to ensure that the UE performs a 
periodical intra frequency reporting and a 
periodical inter frequency reporting. 






1,2 




10 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to 
remove measlds for periodical reporting. 


<— 


RRCConnectionReconfiguration 






11 


The UE transmits an 

RCConnectionReconfigrationComplete 

message 


— > 


RRCConnectionReconfigurationC 
omplete 






12 


Check: does the UE attempt to transmit an 
uplink message for the next 1 0s? 


- 


- 


3 


F 
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Table 8.3.1 .4.3.2-3: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: After the 1st message is 
received, step 1 below shall be repeated every 
time the duration indicated in the IE 
reportlnterval has elapsed 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 2? 


— > 


MeasurementReport 


1 


P 


Table 8.3.1 .4.3.2-4: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: After the 1st message is 
received, step 1 below shall be repeated every 
time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical inter frequency reporting for Cell 3? 


--> 


MeasurementReport 


1 


P 


Table 8.3.1 .4.3.2-5: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: Step 1 below shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 2 
and Cell 4? 


— > 


MeasurementReport 


1,2 


P 


Table 8.3.1 .4.3.2-6: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: Step 1 below shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical inter frequency reporting for Cell 3 
and Cell 6? 


— > 


MeasurementReport 


1,2 


P 


Table 8.3.1 .4.3.2-7: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 




EXCEPTION: Step 1 below shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 4? 


— > 


MeasurementReport 


1,2 


P 
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Table 8.3.1 .4.3.2-8: Parallel behaviour 



St 


Procedure 


■message Sequence 


TP 


Verdict 


U-S 


lUlessage 




EXCEPTION: Step 1 below shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical inter frequency reporting for Cell 6? 


— > 


MeasurementReport 


1,2 


P 



Editor's note: The value and tolerance of the reportlnterval is FFS. 



8.3.1.4.3.3 



Specific message contents 



Editor's note: When default message contents of RRCConnectionReconfiguration in TS36.508 will cover 

measurement configuration the tables for specific message contents below will be updated accordingly. 
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Table 8.3.1.4.3.3-1 RRCConnectionReconfiguration (step 1, Table 8.3.1.4.3.2-2) 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration ::= SEQUENCE { 








measObjectToAddModifyLJst::= SEQUENCE 


2 entries 






(SIZE (1 ..maxObjectld)) OF SEQUENCE { 








measObjectld[1] 


MeasObjectld-MQI 






measObject[1] 


MeasObjectEUTRA-MOl 


Intra frequency 




measObjectld[2] 


MeasObjectld-MQ2 






measObject[2] 
1 


MeasObjectEUTRA-M02 


Inter frequency 




reportConfigToAddModifyLlst ::= SEQUENCE 


1 entry 






(SIZE (L.maxReportConfigld)) OF SEQUENCE { 








reportConfigld[1] 


ReportConfigld-RCI 






reportConfig[1] 
1 


ReportConfigEUTRA- 
RC1 






1 

measldToAddModifyList ::= SEQUENCE (SIZE 


2 entries 






(L.maxMeasId)) OF SEQUENCE { 








measld[1] 


1 






measObjectld[1] 


MeasObjectld-MQI 






reportConfigld[1] 


ReportConfigld-RCI 






measld[2] 


2 






measObjectld[2] 


MeasObjectld-MQ2 






reportConfigld[2] 


ReportConfigld-RCI 






1 

quantityConfig ::= SEQUENCE { 








quantityConfigEUTRA 








filterCoefficient 
1 


FFS 






i 

measGapConfig ::= SEQUENCE { 








gapActivation CHOICE { 








activate SEQUENCE { 








gapPattern ENUMERATED {} 


gpl (FFS) 






startSFN 


FFS 






startSubframeNumber 
} 
} 
} 

}'" 


FFS 






} 
} 
} 
} 

measObjectEUTRA ::= SEOUENCE { 


MeasObjectEUTRA-MOl 






eutra-Carrierlnfo SEQUENCE {}, 




E-UTRA DL 
carrier frequency 
of the serving cell 




measurementBandwidth 




FFS 




offsetFreq 


OdB 


Default 
Neighbour cell list 




cellsToRemoveList 


Not present 






cellsToAddModifyList 


Not present 


Black lists 




blackListedCellsToRemoveLlst 


Not present 






blackListedCellsToAddModifyLlst 
} 


Not present 






measObjectEUTRA ::= SEOUENCE { 


MeasObjectEUTRA-M02 






eutra-Carrierlnfo SEQUENCE {}, 




E-UTRA DL 
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carrier frequency 








different than the 








serving cell 




measurementBandwidth 




FFS 




offsetFreq 


OdB 


Default 
Neighbour cell list 




cellsToRemoveList 


Not present 






cellsToAddModifyList 


Not present 


Black lists 




blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyList 
} 


Not present 






reportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 






triggerType CHOICE { 








periodical SEQUENCE { 








reported 

} 


FALSE 






1 
triggerQuantity 


rsrp 


Reference Signal 
Received Power 




reportQuantity 


sameAsTriggerQuantity 






maxReportCells 


4 


Report Cell 2, Cell 
3, Cell 4 and Cell 
6 
Periodical 




reportlnterval SEQUENCE {} 


FFS seconds 








reporting required 




reportAmount SEQUENCE {} 
} 


Not present 







Table 8.3.1.4.3.3-2 RRCConnectionReconfiguration (step 8, Table 8.3.1.4.3.2-2) 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-6 



Information Element 



Value/remark 



Comment 



Condition 



RRCConnectionReconfiguration ::= SEQUENCE { 
criticalExtensions CHOICE { 
c1 CHOICE! 
rrcConnectionReconfiguration-r8 SEQUENCE { 
measurementConfiguration ::= SEQUENCE { 
measldToRemoveList::= SEQUENCE (SIZE 
(1 ..maxMeasId)) OF SEQUENCE { 
measld[1] 
measld[2] 
} 
} 
} 
} 
} 
} 



1 entry 

1 
2 
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Table 8.3.1.4.3.3-3 MeasurementReport (step 1, Table 8.3.1 

8.3.1.4.3.2-7) 



4.3.2-3, Table 8.3.1.4.3.2-5, Table 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


measuredResults ::= SEQUENCE { 








measid 


1 






measuredResultServing ::= SEQUENCE {} 




FFS 




mobilitylVleasResults CHQICE { 








measResultUstEUTRA ::= SEQUENCE (SIZE 






Table 8.3.1.4.3.2-3 


(L.tnaxCellReport)) OF SEQUENCE { 








physicalCellldentity[1] 


2 


Report Cell 2 




measResultEUTRA[1] ::= SEQUENCE {} 

} 


rsrp 


FFS 




mobilityMeasResults CHQICE { 






Table 8.3.1.4.3.2-5 


measResultUstEUTRA ::= SEQUENCE (SIZE 








(1..maxCellReport)) QF SEQUENCE { 








physicalCellldentity[1] 


2 


Report Cell 2 




measResultEUTRA[1] ::= SEQUENCE {} 


rsrp 


FFS 




physicalCellldentity[2] 


4 


Report Cell 4 




measResultEUTRA[2] ::= SEQUENCE {} 

} 


rsrp 


FFS 




mobilityMeasResults CHQICE { 






Table 8.3.1.4.3.2-7 


measResultUstEUTRA ::= SEQUENCE (SIZE 








(1 ..maxCellReport)) QF SEQUENCE { 








physicalCellldentity[1] 


4 


Report Cell 4 




measResultEUTRA[1] ::= SEQUENCE {} 

} 
} 
} 


rsrp 


FFS 
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Table 8.3.1.4.3.3-4 MasurementReport (step 1, Table 8.3.1.4.3.2-4, Table 8.3.1.4.3.2-6, Table 8.3.1.4.3.2- 

8) 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


measuredResults ::= SEQUENCE { 








measid 


2 






measuredResultServing ::= SEQUENCE {} 




FFS 




mobilitylVleasResults CHQICE { 








measResultUstEUTRA ::= SEQUENCE (SIZE 






Table 8.3.1.4.3.2-4 


(L.tnaxCellReport)) OF SEQUENCE { 








physicalCellldentity[1] 


3 


Report Cell 3 




measResultEUTRA[1] ::= SEQUENCE {} 

} 


rsrp 


FFS 




mobilityMeasResults CHQICE { 






Table 8.3.1.4.3.2-6 


measResultUstEUTRA ::= SEQUENCE (SIZE 








(1..maxCellReport)) QF SEQUENCE { 








physicalCellldentity[1] 


3 


Report Cell 3 




measResultEUTRA[1] ::= SEQUENCE {} 


rsrp 


FFS 




physicalCellldentity[2] 


6 


Report Cell 6 




measResultEUTRA[2] ::= SEQUENCE {} 

} 


rsrp 


FFS 




mobilityMeasResults CHQICE { 






Table 8.3.1.4.3.2-8 


measResultUstEUTRA ::= SEQUENCE (SIZE 








(1 ..maxCellReport)) QF SEQUENCE { 








physicalCellldentity[1] 


6 


Report Cell 6 




measResultEUTRA[1] ::= SEQUENCE {} 

} 
} 
} 


rsrp 


FFS 





8.3.1 .5 Measurement configuration control and reporting / intra E-UTRAN 

measurements: 2 simultaneous event A3 (intra frequency measurements) 



8.3.1.5.1 

(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state and measurements configured for two event A3 at the same 

time} 

ensure that { 

when { Neighbour becomes offset better than serving } 
then { UE sends MeasurementReport with correct measid for event A3 } 



} 

8.3.1.5.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.4.1, 5.5.4.4 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobilityControlInformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> If ihe RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 
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[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measIdList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of frequencies 
(GERAN) to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
blackListedCellsToAddModijyList defined within the VarMeasurementConfiguration for this measid; 

2> else consider a neighbouring cell on the associated frequency to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
MackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration or: 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the VarMeasurementReports does not include an entry for this measid: 

4> include an entry within the VarMeasurementReports for this measid; 

4> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> if the triggerType is set to 'periodical' : 

4> clear the cellsToReportList defined within the VarMeasurementReports for this measid and include 
the applicable cell(s) in the cellsToReportList; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the leaving condition applicable for this event is fulfilled for one or more of the cells included in the 
cellsToReportList defined within the VarMeasurementReports for this measid for a duration exceeding the 
value of timeToTrigger defined within the VarMeasurementConfiguration for this event: 

3> remove the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid; 



[TS 36.331, clause 5.5.4.4] 
The UE shall: 

1> apply inequality A3-1, as specified below, as the entry condition for this event; 

1> apply inequality A3 -2, as specified below, as the leaving condition for this event; 
Inequality A3-1 (Entering condition) 
Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 
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Inequality A3-2 (Leaving condition) 

Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Off 

The variables in the formula are defined as follows: 

Mn is the measurement result of the neighbouring cell. 

Ofn is the frequency specific offset of the frequency of the neighbour cell (equals Ofs for intra-frequency 

measurements and is included in MeasObjectEUTRA corresponding to the inter frequency as offsetFreq for inter- 
frequency measurements) 

Ocn is the cell specific offset of the neighbour cell. If not configured zero offset shall be applied (included in 
MeasObjectEUTRA of the serving frequency as parameter celllndividualOffset for intra-f measurements and 
included in MeasObjectEUTRA corresponding to the inter frequency as parameter celllndividualOffset for inter- 
frequency measurements). 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Ofs is the frequency specific offset of the serving frequency (i.e. offsetFreq within the MeasObjectEUTRA 
corresponding to the serving frequency) 

Ocs is the cell specific offset of the serving cell (included in MeasObjectEUTRA of the serving frequency as 
^aiamsttx celllndividualOffset) 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Off is the offset parameter for this event (i.e. a3-Offset as defined within the VarMeasurementConfiguration for this 
event) 

Mn, Ms are expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Ofn, Ocn, Ofs, Ocs, Hys, Off aie expressed in dB 

[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> set the mobilityMeasResults to include all cells included in the cellsToReportList as defined within the 
VarMeasurementReports for this measid 

1> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, ordered as follows: 

2> If for E-UTRA the reportQuantity is set as 'both': 

3> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 
2> else: 

3> include the cells in order of decreasing reportQuantity, i.e. the best cell is included fu'st. 

Editor's note: It is EPS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 

1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid hy 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than to 
reportAmount as defined within the reporting configuration for this event as defined in variable 
VarMeasurementConfiguration: 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 
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1> if the measured results are for CDMA: 

2> set the preRegistrationStatus to the UE's cdma upper layer's HRPD preRegistrationStatus; 

l> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 



8.3.1.5.3 

8.3.1.5.3.1 

System Simulator: 
- Cell 1 and Cell 2 

UE: 

None. 



Test description 
Pre-test conditions 



Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18] 



8.3.1.5.3.2 



Test procedure sequence 



Table 8.3.1.5.3.2-1 illustrates the downlink power levels to be applied for Cell 1 and Cell 2 at various time instants of 
the test execution. Row marked "TO" denotes the initial conditions, while rows marked "TT'and "T2" are to be applied 
subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 

Table 8.3.1.5.3.2-1 : Power levels 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 
(FFS) 


P02 
(FFS) 


P01 and P02 shall be such that entry condition for event 
A3 (measid 1 & 2) is not satisfied: 

Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Ojf 


Tl 


Ro 


dBm 


P11 
(FFS) 


P12 

(FFS) 


P1 1 and PI 2 shall be such that entry condition for event 

A3 (measid 1) is satisfied: 

Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Ojf 


T2 


Ro 


dBm 


P21 

(FFS) 


P22(FFS 
) 


P21 and P22 shall be such that entry condition for event 

A3 (measid 2) is satisfied: 

Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Ojf 
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Table 8.3.1.5.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LIE measurement and reporting for two 
event A3 (measid 1 and measid 2) with 
different parameters. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


Checl<: does the UE transmit a 
MeasurementReport message within the next 
10s? 


— > 


MeasurementReport 


1 


F 


4 


SS re-adjusts the cell-specific reference signal 
level according to row "T1" in table 
8.3.1.5.3.2.-1. 










5 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 (measid 1) with the measured RSRP value 
for Cell 2? 


— > 


MeasurementReport 


1 


P 


6 


SS re-adjusts the cell-specific reference signal 
level according to row "T2" in table 
8.3.1.5.3.2.-1. 










7 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 (measid 2) with the measured RSRP value 
for Cell 2? 


— > 


MeasurementReport 


1 


P 


8 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 1? 











Editors note: When test tolerances in TS36.508 will cover measurements steps 4 and 6 above will take them into 
account. 



8.3.1.5.3.3 



Specific message contents 



Table 8.3.1.5.3.3-1 RRCConnectionReconfiguration (step 1): measurementConfiguration test specific 

information elements: FFS 

Table 8.3.1.5.3.3-2 MeasurementReport (step 5 ): measuredResults test specific information 

elements: FFS 

Table 8.3.1.5.3.3-3 MeasurementReport (step 7 ): measuredResults test specific information 

elements: FFS 



8.3.1 .6 Measurement configuration control and reporting / intra E-UTRAN 

measurements: 2 simultaneous events A2 and A3 (Inter frequency 
measurements) 



8.3.1.6.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state and measurements configured for event A2 and event A3 
ensure that { 

when { Serving becomes worse than threshold } 
then { UE sends MeasurementReport for event A2 } 
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(2) 

with { UE in E-UTRA RRC_CONNECTED state and measurements configured for event A2 and event A3 } 
ensure that { 

when { Neighbour becomes offset better than serving } 
then { UE sends Measurement J?eport for event A3 } 
} 

8.3.1.6.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.4.1, 5.5.4.3, 5.5.4.4 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobility Controllnformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> \i ihQ RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measIdList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of frequencies 
(GERAN) to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
blackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> else consider a neighbouring cell on the associated frequency to be applicable as follows: 



3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
HackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration or: 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the VarMeasurementReports does not include an entry for this measid: 

4> include an entry within the VarMeasurementReports for this measid; 

4> set the numberOfReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> if the triggerType is set to 'periodical': 
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4> clear the cellsToReportList defined within the VarMeasurementReports for this measid and include 
the applicable cell(s) in the cellsToReportList; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the leaving condition applicable for this event is fulfilled for one or more of the cells included in the 
cellsToReportList defined within the VarMeasurementReports for this measid for a duration exceeding the 
value of timeToTrigger defined within the VarMeasurementConfiguration for this event: 

3> remove the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid; 

[TS 36.331, clause 5.5.4.3] 

The UE shall: 

1> apply inequality A2-1, as specified below, as the entry condition for this event; 

1> apply inequality A2-2, as specified below, as the leaving condition for this event; 
Inequality A2- 1 (Entering condition) 
Ms — Hys < Thresh 

Inequality A2-2 (Leaving condition) 
Ms + Hys> Thresh 
The variables in the formula are defined as follows: 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Thresh is the threshold parameter for this event (i.e. a2-Threshold as defined within the 
VarMeasurementConfiguration for this event) 

Ms is expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Hys is expressed in dB 

Thresh is expressed in dBm in case Ms is expressed in dBm; otherwise it is expressed in dB 
[TS 36.331, clause 5.5.4.4] 
The UE shall: 

1> apply inequality A3-1, as specified below, as the entry condition for this event; 

1> apply inequality A3 -2, as specified below, as the leaving condition for this event; 
Inequality A3-1 (Entering condition) 
Mn + Ofn + Ocn - Hys >Ms + Ofs + Ocs + Off 
Inequality A3-2 (Leaving condition) 
Mn + Ofn+Ocn+Hys < Ms + Ofs + Ocs + Off 
The variables in the formula are defined as follows: 

Mn is the measurement result of the neighbouring cell. 

Ofn is the frequency specific offset of the frequency of the neighbour cell (equals Ofs for intra-frequency 

measurements and is included in MeasObjectEUTRA corresponding to the inter frequency as offsetFreq for inter- 
frequency measurements) 
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Ocn is the cell specific offset of the neighbour cell. If not configured zero offset shall be applied (included in 
MeasObjectEUTRA of the serving frequency as parameter celllndividualOjfset for intra-f measurements and 
included in MeasObjectEUTRA corresponding to the inter frequency as parameter celllndividualOjfset for inter- 
frequency measurements). 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Ofs is the frequency specific offset of the serving frequency (i.e. ojfsetFreq within the MeasObjectEUTRA 
corresponding to the serving frequency) 

Ocs is the cell specific offset of the serving cell (included in MeasObjectEUTRA of the serving frequency as 
parameter celllndividualOjfset) 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Off is the offset parameter for this event (i.e. a3-Offset as defined within the VarMeasurementConfiguration for this 
event) 

Mn, Ms are expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Ofn, Ocn, Ofs, Ocs, Hys, Off are expressed in dB 

[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> set the mobilityMeasResults to include all cells included in the cellsToReportList as defined within the 
VarMeasurementReports for this measid 

1> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, ordered as follows: 

2> If for E-UTRA the reportQuantity is set as 'both' : 

3> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 
2> else: 

3> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 

Editor's note: It is EPS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 

1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid hy 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than to 
reportAmount as defined within the reporting configuration for this event as defined in variable 
VarMeasurementConfiguration: 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 



1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FES which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 
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Test description 
Pre-test conditions 



8.3.1.6.3 

8.3.1.6.3.1 

System Simulator: 
- Cell 1 and Cell 3 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 



8.3.1.6.3.2 



Test procedure sequence 



Table 8.3.1.6.3.2-1 illustrates the downlink power levels to be applied for Cell 1 and Cell 3 at various time instants of 
the test execution. Row marked "TO" denotes the initial conditions, while rows marked "TT'and "T2" are to be applied 
subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 

Table 8.3.1.6.3.2-1 : Power levels 





Parameter 


Unit 


Cein 


Cell 3 


Remark 


TO 


Ro 


dBm 


P01 
(FFS) 


P02 
(FFS) 


P01 and P02 shall be such that entry condition for event 
A2 and event A3 is not satisfied: 
Ms + Hys> Thresh 
AND 

Mn + Ofn + Ocn + Hys <Ms + Ofs + Ocs + Off 


Tl 


Ro 


dBm 


P11 
(FFS) 


P12 

(FFS) 


P1 1 shall be such that entry condition for event A2 is 

satisfied: 

Ms - Hys < Thresh 

AND 

P1 1 and P12 shall be such that entry condition for event 

A3 is not satisfied: 

Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Off 


T2 


Ro 


dBm 


P21 

(FFS) 


P22(FFS 
) 


P21 and P22 shall be such that entry condition for event 
A3 is satisfied: 

Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 
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Table 8.3.1.6.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LIE measurement and reporting for event 
A2 and event A3 (inter frequency 
measurement) 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


Check: does the UE transmit a 
MeasurementReport message within the next 
10s? 


— > 


MeasurementReport 


1 


F 


4 


SS re-adjusts the cell-specific reference signal 
level according to row "T1" in table 
8.3.1.6.3.2.-1. 










5 


Check: does the UE transmit a 
MeasurementReport message to report event 
A2 with the measured RSRP value for Cell 1 ? 


— > 


MeasurementReport 


1 


P 


6 


SS re-adjusts the cell-specific reference signal 
level according to row "T2" in table 
8.3.1.6.3.2.-1. 










7 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 with the measured RSRP value for Cell 3? 


— > 


MeasurementReport 


2 


P 


8 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 1? 











Editors note: When test tolerances in TS36.508 will cover measurements steps 4 and 6 above will take them into 
account. 

Editor's note: It is FFS if Cell 3 is included in the MeasurementReport in step 5. 



8.3.1.6.3.3 



Specific message contents 



Table 8.3.1.6.3.3-1 RRCConnectionReconfiguration (step 1): measurementConfiguration test specific 

information elements: FFS 

Table 8.3.1.6.3.3-2 MeasurementReport (step 5 ): measuredResults test specific information 

elements: FFS 

Table 8.3.1.6.3.3-3 MeasurementReport (step 7 ): measuredResults test specific information 

elements: FFS 

8.3.1 .7 Measurement configuration control and reporting/ intra E-UTRAN 

measurements: blacklisting 



8.3.1.7.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state and meausurement configured for event A3 reporting } 
ensure that { 

when { Blacklisted neighbour cell satisfies entry condition for event A3 } 
then { It is not considered in event evaluation and UE does not send MeasurementReport message 



(2) 

with { UE in E-UTRA RRC_CONNECTED state and meausurement reporting triggered by event A3 is ongoing} 
ensure that { 

when { Blacklisted neighbour cell satisfies entry condition for event A3 } 
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then { It is not considered in measurement reporting } 
} 

8.3.1.7.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in; TS 36.331, clauses 5.5.1, 5.5.4.1, 
5.5.4.4 and 5.5. 5. 

[TS 36.331, clause 5.5.1] 

The UE reports measurement information in accordance with the measurement configuration as provided by E- 
UTRAN. E-UTRAN provides the measurement configuration applicable for a UE in RRC_CONNECTED state by 
means of dedicated signalling, i.e. using the RRCConnectionReconfiguration message. 



For intra-frequency and inter-frequency measurements a measurement object is a single E-UTRA carrier 
frequency. Associated with this carrier frequency, E-UTRAN can configure a list of cell specific offsets and a 
list of 'blacklisted' cells. Blacklisted cells are not considered in event evaluation or measurement reporting. 



[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measldList within VarMeasurementConfiguration: 

2> if the entry condition applicable for this event, i.e. the event corresponding with the eventid of the 
corresponding reportConfig within VarMeasurementConfiguration, is fulfilled for one or more cells 
applicable for this event for a duration exceeding the value of timeToTrigger defined for this event within the 
VarMeasurementConfiguration 

3> if the reportlnterval defined within the VarMeasurementConfiguration for this event is not equal to 0: 

4> set the periodicalReportingOngoing defined within the VarEventsTriggered for this event to TRUE; 

3> set the numberOJReportsSent defined within the VarEventsTriggered for this event to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the Y arEventsTrigge red for this 
event, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the reportlnterval defined within the VarMeasurementConfiguration for this event is not equal to 0: 

4> set the periodicalReportingOngoing defined within the VarEventsTriggered for this event to TRUE; 

3> set the numberOJReportsSent defined within the VarEventsTriggered for this event to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarEventsTriggered for this 
event, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the leaving condition applicable for this event is fulfilled for one or more of the cells included in the 

cellsToReportList defined within the VarEventsTriggered for this event for a duration exceeding the value of 
timeToTrigger defined within the VarMeasurementConfiguration for this event: 

3> remove the concerned cell(s) in the cellsToReportList defined within the VarEventsTriggered for this 
event; 
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[TS 36.331, clause 5.5.4.4] 
The UE shall: 

1> apply equation A3-1, as specified below, as the entry condition for this event; 

1> apply equation A3-2, as specified below, as the leaving condition for this event; 
Equation A3-1 (Entering condition) 
Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 
Equation A3 -2 (Leaving condition) 
Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Off 
The variables in the formula are defined as follows: 

Mn is the measurement result of the neighbouring cell. 

Ofn is the frequency specific offset of the frequency of the neighbour cell 

Ocn is the cell specific offset of the neighbour cell. If not configured zero offset shall be applied. 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Ofs is the frequency specific offset of the serving frequency (i.e. offsetFreq within MeasObjectEUTRA) 

Ocs is the cell specific offset of the serving cell (i.e. servingCellOffset within MeasObjectEUTRA) 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Off is, the offset parameter for this event (i.e. a3-0ffset as defined within the VarMeasurementConfiguration for this 
event) 

Mn, Ms are expressed in dBm 

Ofn, Ocn, Ofs, Ocs, Hys, Offaie expressed in dB 

[TS 36.331, clause 5.5.5] 

For the measld for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measld to the measurement identity that triggered the measurement reporting; 

1> set the mobilityMeasResults to include all cells included in the cellsToReportList as defined within the 
VarEventsTriggered for this event 

1> for each included cell include the measured results in accordance with the reportConfigList defined in variable 
VarMeasurementConfiguration for that measurement; 

1> include the cells in order of decreasing reportingQuantity, i.e. the best cell is included first. 

Editor's note: It is FFS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 

1> increment the numberOJReportsSent as defined within the VarEventsTriggered for this event by 1; 

1> if the periodicalReportingOngoing defined within the VarEventsTriggered for this event is set to FALSE or 

1> if the numberOfReportsSent as defined within the VarEventsTriggered for this event is equal to report Amount as 
defined within the reporting configuration for this event as defined in variable VarMeasurementConfiguration: 

2> set the periodicalReportingOngoing defined within the V arEventsTrigge red for this event to FALSE; 

l> else: 
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2> start a timer with the value of reportlnterval as defined within the VarMeasurementConfiguration for this 
event; 

1> if the measured resuhs are for CDMA: 

2> set the preRegistrationStatus to the UE's cdma upper layer's HRPD preRegistrationStatus; 

1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 

Editor's note: It is FFS if, for the case of a SON report of the strongest cell(s) on the carrier, the UE is required to 
report more than one cell. 



8.3.1.7.3 
8.3.1.7.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1, Cell 2 and Cell 4: 

Cell 1 is the serving cell 

Cell 2 and Cell 4 are intra-frequency neighbour cells 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.3.1.7.3.2 



Test procedure sequence 



Table 8.3.1.7.3.2-1 illustrates the downlink power levels to be applied for Cell 1, Cell 2 and Cell 4 at various time 
instants of the test execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl", "T2" and "T3" 
are to be applied subsequently. The exact instants on which these values shall be applied are described in the texts in 
this clause. 

Table 8.3.1 .7.3.2-1 : Power level 





Parameter 


Unit 


Cein 


Cell 2 


Cell 4 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P04 (FFS) 


Power levels shall be such that that exit 
condition for event A3 is satisfied for all cells 
(M2 + Hys < M1 and M2 + Hys < M1) with all 
offset parameters set to dB. 


11 


P11 (FFS) 


PI 2 (FFS) 


P04 (FFS) 


P11 and PI 2 shall be such that measurement 
results for Cell 1 (M1) and Cell 2 {M2) satisfy 
entry condition for event A3 (M2 - Hys > Ml). 


12 


P11 (FFS) 


P12(FFS) 


P24 (FFS) 


P24 shall be such that measurement results 
for Cell 1 {M1) and Cell 4 {M4) satisfy entry 
condition for event A3 {M4 - Hys > M1). 
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Table 8.3.1 .7.3.2-2 : Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intraLTE measurement and reporting for event 
A3. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


SS re-adjusts the cell-specific reference signal 
levels according to row "T1 " in table 
8.3.1.7.3.2.-1. 










4 


Check: does the UE transmit a 
MeasurementReport messages within the next 
10s? 




MeasurementReport 


1 


F 


5 


SS re-adjusts the cell-specific reference signal 
levels according to row "T2" in table 
8.3.1.7.3.2.-1. 










6 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 with the measured RSRP values for Cell 
1 and Cell 4 without Cell 2 results? 


-> 


MeasurementReport 


2 


P 


7 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to 
remove Cell 2 from the blacklisted cell list. 


<— 


RRCConnectionReconfiguration 






8 


The UE transmits an 

RCConnectionReconfigrationComplete 

message 


— > 


RRCConnectionReconfigurationC 
omplete 






9 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 with the measured RSRP values for Cell 1 , 
Cell 2 and Cell 4? 


— > 


MeasurementReport 


1,2 


P 



Editors note: When test tolerances in TS36.508 will cover measurements steps 3, 5 and 10 above will take them 



mto account 



8.3.1.7.3.3 



Specific message contents 



Editors note: When default message contents of RRCConnectionReconfiguration in TS36.508 will cover 
measurement configuration it will be referenced in the derivation path in the table below. 
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Table 8.3.1.7.3.3-1 RRCConnectionReconfiguration (step 1): measurementConfiguration test specific 

information elements 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectlonReconfiguration-r8 SEOUENCE { 








measurementConfiguration ::= SEQUENCE { 








measObjectToAddModifyLJst::= SEQUENCE 


1 entry 






(SIZE (1 ..maxObjectld)) OF SEQUENCE { 








measObjectld[1] 


IdMeasObjectEUTRA- 
M01 






measObject[1] 
1 


MeasObjectEUTRA-MOl 






reportConfigloAddModifyList ::= SEQUENCE 


1 entry 






(SIZE (L.maxReportConfigld)) OF SEQUENCE { 








reportConfigld[1] 


IdReportConfigEUTRA- 
RC1 






reportConfig[1] 
1 


ReportConfigEUTRA- 
RC1 






measldToAddModifyList ::= SEQUENCE (SIZE 


1 entry 






(1 ..maxMeasId)) OF SEQUENCE { 








measld[1] 


1 






measObjectld[1] 


IdlVleasQbjectEUTRA- 
M01 






reportConfigld[1] 
1 


IdReportConfJgEUTRA- 
RC1 






1 

quantityConfig ::= SEQUENCE { 








quantityConfigEUTRA 








filterCoefficient 

} 

} 

} 
1 


FFS 






1 
} 
} 

measObjectEUTRA ::= SEOUENCE { 


MeasObjectEUTRA-MOl 






eutra-Carrierlnfo SEQUENCE {}, 




Identifies E-UTRA 
carrier frequency 




measurementBandwidth 




FFS 




offsetFreq 


OdB 


Default 




servingCellQffset 


OdB 


Default (FFS) 
Neighbour cell list 




cellsToRemoveList 


Not present 






cellsToAddModifyLlst ::= SEQUENCE (SIZE 


2 entries 


Add Cell 2 and 




(L.maxCellMeas)) OF SEQUENCE { 




Cell 4 




celllndex[1] 


1 


Entry index 




physicalCellldentity[1] 


2 


FFS 




celllndividualQffset[1] 


OdB 






celllndex[2] 


2 


Entry index 




physicalCellldentity[2] 


4 


FFS 




celllndividualOffset[2] 
1 


OdB 






1 




Black lists 




blackListedCellsToRemoveList 


Not present 






blackListedCellsToAddModifyList ::= SEQUENCE 


1 entry 


Add Cell 2 




(SIZE (L.maxCellMeas)) OF SEOUENCE { 








celllndex[1] 


1 


Entry index 




physicalCellldentity[1] 
} 
} 


2 


FFS 
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reportConfigEUTRA ::= SEQUENCE { 


ReportConfigEUTRA- 
RC1 






eventid CHOICE { 
eventAS SEQUENCE { 
a3-0ffset 
} 


OdB 






triggerQuantity 


rsrp 


Reference Signal 
Received Power 




hysteresis 
timeToTrigger 
reportQuantity 
maxReportCells 


TBD [ > dB] 
seconds 

sameAsTriggerQuantity 
3 


FFS 

Report Cell 1,Cell 
2 and Cell 4 




reportlnterval SEQUENCE {} 
reportAmount SEQUENCE {} 
} 


Not present 
Not present 







Table 8.3.1.7.3.3-2 RRCConnectionReconfiguration (step 7): measurementConfiguration test specific 

information elements 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-6 


Information Element 


Value/remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectlonReconfiguration-rS SEQUENCE { 








measurementConfiguration ::= SEQUENCE { 








measObjectToAddModifyList::= SEQUENCE 


1 entry 






(SIZE (1 ..maxObjectId)) OF SEQUENCE { 








measObjectld[1] 


IdMeasQbjectEUTRA- 
M01 






measObject[1] 

} 

} 

} 
1 


MeasObjectEUTRA-MOl 






} 
} 

measObjectEUTRA ::= SEQUENCE { 


MeasObjectEUTRA-MOl 






eutra-Carrierlnfo SEQUENCE {}, 




Identifies E-UTRA 
carrier frequency 




measurementBandwidth 




FFS 




offsetFreq 


OdB 


Default 




servingCellQffset 


OdB 


Default (FFS) 
Neighbour cell list 




cellsToRemoveLlst 


Not present 






cellsToAddModifyList 


Not present 


Black lists 




blackListedCellsToRemoveList ::= SEQUENCE 


1 entry 


Remove Cell 2 




(SIZE (L.maxCellMeas)) OF SEQUENCE { 








celllndex[1] 


1 


Entry index 




1 
blackListedCellsToAddModifyLlst 

} 


Not present 
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Table 8.3.1.7.3.3-3 MeasurementReport {step 6): measuredResults test specific information elements 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


measuredResults ::= SEQUENCE { 








measid 


1 






measuredResultServing ::= SEQUENCE {} 




FFS 




mobilitylVleasResults CHQICE { 








measResultUstEUTRA ::= SEQUENCE (SIZE 








(L.tnaxCellReport)) OF SEQUENCE { 








physicalCellldentity[1] 


4 


Report Cell 4 




measResultEUTRA[1] ::= SEQUENCE {} 


rsrp 


FFS 




physicalCellldentity[2] 


1 


Report Cell 1 




measResultEUTRA[2] ::= SEQUENCE {} 
} 
} 
} 


rsrp 


FFS 





Table 8.3.1.7.3.3-4 MeasurementReport {step 9): measuredResults test specific information elements 



Derivation Path: 36.508 clause 4.6.1 table 4.6.1-3 


Information Element 


Value/remark 


Comment 


Condition 


measuredResults ::= SEQUENCE { 








measid 


1 






measuredResultServing ::= SEQUENCE {} 




FFS 




mobilityMeasResults CHQICE { 








measResultUstEUTRA ::= SEQUENCE (SIZE 








(1..maxCellReport)) OF SEQUENCE { 








physicalCellldentity[1] 


2 


Report Cell 2 




measResultEUTRA[1] ::= SEQUENCE {} 


rsrp 


FFS 




physicalCellldentity[2] 


4 


Report Cell 4 




measResultEUTRA[2] ::= SEQUENCE {} 


rsrp 


FFS 




physicalCellldentity[2] 


1 


Report Cell 1 




measResultEUTRA[2] ::= SEQUENCE {} 

} 
} 
} 


rsrp 


FFS 





8.3.1 .8 Measurement configuration control and reporting / intra E-UTRAN 

measurements: handover (IE measurement configuration present) 



8.3.1.8.1 
(1) 



Test Purpose (TP) 



with { UE having completed the radio bearer establishment, initial security activation procedure and 
performed the intra frequency measurement } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControlInformation and an IE measurementConfiguration for removing intra frequency 
measurement } 

then { UE performs intra frequency handover and stops the intra frequency measurement } 



8.3.1.8.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.3.5.4, 
5.5.2.2 and 5.5.2.6. 

[TS 36.331, clause 5.3.5.4] 
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NOTE 1: The UE should perform the handover as soon as possible following the reception of the RRC message 

triggering the handover, which could be before confirming successful reception (HARQ and ARQ) of this 

message. 

If the RRCConnectionReconfiguration message includes the mobilityControlInformation and the UE is able to comply 
with the configuration included in this message, the UE shall: 

1> stop timer T310 and T312, if running; 

1> start timer T304; 

1> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

2> perform the Radio resource configuration procedure as specified in 5.3.10; 

1> set the C-RNTI to the value of the newUE-Identity; 

1> indicate the occurrence of handover to PDCP; 

1> if the eutra-CarrierFreq is included: 

2> consider the target cell to be one on the frequency indicated by the eutra-CarrierFreq with a physical cell 
identity indicated by the targetCellldentity; 

1> else: 

2> consider the target cell to be one on the current frequency with a physical cell identity indicated by the 
targetCellldentity; 

1> if the dl-Bandwidth is included: 

2> for the target cell, apply the downlink bandwidth indicated by the dl-Bandwidth; 
1> else: 

2> for the target cell, apply the same downlink bandwidth as for the current cell; 
1> if the ul-Bandwidth is included: 

2> for the target cell, apply the uplink bandwidth indicated by the ul-Bandwidth; 
1> else: 

2> for the target cell, apply the same uplink bandwidth as for the current cell; 
1> configure lower layers in accordance with the received radioResourceConfigCommon; 
1> \f ihQ RRCConnectionReconfiguration message includes the securityConfiguration: 

2> apply the AS-derived keys associated with the AS-base key indicated by the keylndicator; 

2> configure lower layers to apply the indicated integrity protection algorithm immediately, i.e. the indicated 
integrity protection configuration shall be applied to all subsequent messages received and sent by the UE, 
including the message used to indicate the successful completion of the procedure; 

2> configure lower layers to apply the indicated ciphering algorithm immediately, i.e. the indicated ciphering 
configuration shall be applied to all subsequent messages received and sent by the UE, including the message 
used to indicate the successful completion of the procedure; 

1> \f ihQ RRCConnectionReconfiguration message includes the measurementConfiguration: 

2> perform the Measurement configuration procedure as specified in 5.5.2; 

1> reset MAC and re-establish RLC for all RBs that are established; 

NOTE 2: The handling of the radio bearers after the successful completion of handover, e.g. the re-transmission of 
unacknowledged PDCP SDUs (as well as the associated status reporting), the handling of the SN and the 
HEN, is specified in [8]. 
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1> synchronise to the DL of the target cell; 

1> submit the RRCConnectionReconfigurationComplete message to lower layers for transmission using the new 
configuration; 

1> If MAC successfully completes the random access procedure: 

2> stop timer T304; 

2> If the RRCConnectionReconfiguration message includes the radioResourceConfiguration: 

3> perform the physical layer reconfiguration related actions applicable upon successfully completing the 
handover as specified in 5.3.10.5; 

2> the procedure ends. 

Editor's note: It has been agreed that the UE is not required to determine the SEN of the target cell by acquiring 
system information from that cell. 

Editor's note The handling of the radio configuration is covered by the general reconfiguration procedure. It has 
been agreed that the configuration used in the target cell may either be specified as a delta to the one 
used in the serving cell or by providing the full configuration (signalling details are FES) 

Editor's note Currently it is specified that the keylndicator always needs to be provided upon handover as a result of 
which the securityConfiguration becomes mandatory in case of handover. If however the 
securityConfiguration would be optional in case of handover, the case the IE is not included needs to 
be covered also. 

[TS 36.331, clause 5.5.2.2] 

The UE shall: 

1> for each measid value included in the measIdToRemoveList: 

2> remove the entry, from the parameter measIdList within VarMeasurementConfiguration, with the 
corresponding measid value; 

Editors note It has been agreed that the UE should NOT autonomously delete any unused measurement objects or 
reporting configurations. 

[TS 36.331, clause 5.5.2.6] 

The UE shall: 

1> for each reportConfigId value included in the reportConfigToRemoveList: 

2> remove, from the parameter reportConfigList within VarMeasurementConfiguration, the entry with the 
corresponding reportConfigId value; 

2> if the removed entry included t321: 

3> Stop timer T321, if running; 

2> remove, from the parameter measIdList within VarMeasurementConfiguration, the entry(ies) with the 
corresponding reportConfigId value, if included; 

8.3.1.8.3 Test description 

8.3.1.8.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 
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UE: 

None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell 1. 
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8.3.1.8.3.2 



Test procedure sequence 



Table 8.3.1.8.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra frequency measurement. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of intra 
frequency measurement. 


-> 


RRCConnectionReconfigurationC 
ompiete 






3 


The UE transmits a MeasurementReport 
message to perform periodical reporting for 
Cell 2. 


-> 


MeasurementReport 








EXCEPTION: In parallel to the events 
described in steps 4 to 6 the steps specified in 
Table 8.3.1 .8.3.2-2 should take place. 










4 


The SS changes Cell 1 and Cell 2 parameters 
so that the measurement reporting criteria is 
met. 










5 


The UE transmits a MeasurementReport 
message to report the event A3 with the 
measured TBD value for Cell 2. 


-> 


MeasurementReport 






6 


The SS transmits an 

RRCConnectionReconfiguration message with 
an IE measurementConfiguration ^or removing 
periodical reporting, to order the UE to perform 
intra frequency handover to Cell 2. 


<— 


RRCConnectionReconfiguration 


1 




7 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message to Cell 2? 


-> 


RRCConnectionReconfigurationC 
ompiete 


1 


P 


8 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical reporting within the time indicated in 
the IE reportlnten/aR 


-> 


MeasurementReport 


1 


F 


9 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2? 






1 


P 



Table 8.3.1 .8.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: The step 1 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


The UE transmits a MeasurementReport 
message to perform periodical reporting for 
Cell 2. 


-> 


MeasurementReport 







8.3.1 .8.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 
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Table 8.3.1.8.3.3-1 : RRCConnectionReconfiguration (step 1, Table 8.3.1.8.3.2-1) 

FFS 

Table 8.3.1.8.3.3-2: RRCConnectionReconfigurationComplete (step 2 and step 7, Table 8.3.1.8.3.2-1) 

FFS 

Table 8.3.1.8.3.3-3: MeasurementReport {step 3, Table 8.3.1.8.3.2-1) 

FFS 

Table 8.3.1.8.3.3-4: MeasurementReport (step 5, Table 8.3.1.8.3.2-1) 

FFS 

Table 8.3.1.8.3.3-5: RRCConnectionReconfiguration (step 6, Table 8.3.1.8.3.2-1) 

FFS 



Table 8.3.1.8.3.3-6: MeasurementReport {step 1, Table 8.3.1.8.3.2-2) 



FFS 



8.3.1 .9 Measurement configuration control and reporting / intra E-UTRAN 

measurements: intra-frequency handover (IE measurement configuration not 
present) 

Editor's Note: This section is based on 36.331 v8.2.0 i.e. after RAN#40 + R2 -083795. 

8.3.1 .9.1 Test Purpose (IP) 
(1) 

with { UE having completed the radio bearer establishment, initial security activation procedure and 
performed the intra frequency and inter frequency measurements } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControlInformation and not including an IE measurementConf iguration } 

then { UE performs intra frequency handover and continues the intra frequency and inter 
frequency measurements } 
} 

8.3.1.9.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.5.6.1.2. 

[TS 36.331, clause 5.5.6.1.2] 

The UE shall: 

1> If the RRCConnectionReconfiguration message triggering the handover does not include the IE measurement 
configuration: 

2> continue the intra-frequency, inter-frequency and inter-RAT measurements without modifying the 
measurement configuration. 
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8.3.1.9.3 
8.3.1.9.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1 , Cell 2, Cell 3 and Cell 4 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell 1. 



8.3.1.9.3.2 



Test procedure sequence 



Table 8.3.1.9.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra and inter frequency measurements. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of intra and inter 
frequency measurements. 


— > 


RRCConnectionReconfigurationC 
omplete 








EXCEPTION: In parallel to the events 
described in steps 3 to 5 the steps specified in 
Table 8.3.1 .9.3.2-2 should take place. 












EXCEPTION: In parallel to the events 
described in steps 3 to 5 the steps specified in 
Table 8.3.1 .9.3.2-3 should take place. 










3 


Wait for 30 s to ensure that the UE performs a 
periodical intra frequency reporting and a 
periodical inter frequency reporting. 










4 


The SS transmits an 

RRCConnectionReconfiguration message 
without an IE measurementConfiguration, to 
order the UE to perform intra frequency 
handover to Cell 2. 


<— 


RRCConnectionReconfiguration 


1 




5 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message to Cell 2? 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 




EXCEPTION: In parallel to the events 
described in steps 6 to 7 the steps specified in 
Table 8.3.1 .9.3.2-4 should take place. 












EXCEPTION: In parallel to the events 
described in steps 6 to 7 the steps specified in 
Table 8.3.1 .9.3.2-5 should take place. 










6 


Wait for 30 s to ensure that the UE performs a 
periodical intra frequency reporting and a 
periodical inter frequency reporting. 










7 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2? 






1 
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Table 8.3.1 .9.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: The step 1 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


The UE transmits a MeasurementReport 
message to perform periodical intra frequency 
reporting for Cell 2 and Cell 4. 


— > 


MeasurementReport 






Table 8.3.1 .9.3.2-3: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: The step 1 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


The UE transmits a MeasurementReport 
message to perform periodical inter frequency 
reporting for Cell 3. 


— > 


MeasurementReport 







Table 8.3.1 .9.3.2-4: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 1 
and Cell 4. 


— > 


MeasurementReport 


1 


P 




EXCEPTION: The step 2 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










2 


The UE transmits a IVIeasurementReport 
message to perform periodical intra frequency 
reporting for Cell 1 and Cell 4. 


— > 


MeasurementReport 






Table 8.3.1 .9.3.2-5: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical inter frequency reporting for Cell 3. 


— > 


MeasurementReport 


1 


P 




EXCEPTION: The step 2 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










2 


The UE transmits a MeasurementReport 
message to perform periodical inter frequency 
reporting for Cell 3. 


--> 


MeasurementReport 







8.3.1 .9.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 

Table 8.3.1 .9.3.3-1 : RRCConnectionReconfiguration (step 1 , Table 8.3.1 .9.3.2-1) 

FFS 
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Table 8.3.1.9.3.3-2: RRCConnectionReconfigurationComplete (step 2 and step 5, Table 8.3.1.9.3.2-1) 

FFS 

Table 8.3.1.9.3.3-3: RRCConnectionReconfiguration (step 4, Table 8.3.1.9.3.2-1) 

FFS 

Table 8.3.1.9.3.3-4: MeasurementReport (step 1, Table 8.3.1.9.3.2-2) 

FFS 

Table 8.3.1.9.3.3-5: MeasurementReport (step 1, Table 8.3.1.9.3.2-3) 

FFS 

Table 8.3.1.9.3.3-6: MeasurementReport (step 1 and step 2, Table 8.3.1.9.3.2-4) 

FFS 

Table 8.3.1.9.3.3-7: MeasurementReport (step 1 and step 2, Table 8.3.1.9.3.2-5) 

FFS 

8.3.1 .10 Measurement configuration control and reporting / intra E-UTRAN 

measurements: inter-frequency handover (IE measurement configuration not 
present) 

Editor's Note: This section is based on 36.331 v8.2.0 i.e. after RAN#40 + R2 -083795. 

8.3.1.10.1 Test Purpose (IP) 
(1) 

with { UE having completed the radio bearer establishment, initial security activation procedure and 
performed the intra frequency and inter frequency measurements } 
ensure that { 

when { UE receives an RRCConnectionReconfiguration message including an IE 
mobilityControlInformation indicating a different E-UTRA frequency and not including an IE 
measurementConfiguration } 

then { UE performs inter frequency handover, continues the intra frequency measurement and stops 
inter frequency measurement } 
} 

8.3.1.10.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.5.6.1.3. 

[TS 36.331, clause 5.5.6.1.3] 

The UE shall: 

1> If the iRRCConnectionReconfiguration message triggering the handover does not include the IE measurement 
configuration: 

2> continue the intra-frequency measurements as follows: 

3> for each imeasld value in the parameter measIdList within VarMeasurementConfiguration that is linked 
to the measObjId value in the parameter measObjectList within VarMeasurementConfiguration whose 
eutra-Carrierlnfo is set to the source carrier frequency: 

4> link this measid value to the measObjId value in the parameter measObjectList within 
VarMeasurementConfiguration whose eutra-Carrierlnfo is set to the target frequency; 

2> stop all inter-frequency and inter-RAT measurements while keeping the measurement configuration 
unchanged; 
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NOTE 2 The UE resumes the applicable inter-frequency measurements after the E-UTRAN has configured the 
corresponding measurement object and activated the (corresponding) measurement gap(s) 

2> deactivate the measurement gap, if activated. 

NOTE If the IE measurementConfiguration is included, then the normal procedure in 5.5.2 is performed 



8.3.1.10.3 
8.3.1.10.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1, Cell 2, Cell 3, Cell 4 and Cell 6(FFS) 

Editor's Note: It is necessary to add a cell on using frequency f2 to TS 36.508. 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell 1. 



8.3.1.10.3.2 



Test procedure sequence 



Table 8.3.1.10.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup intra and inter frequency measurements. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of intra and inter 
frequency measurements. 


— > 


RRCConnectionReconfigurationC 
omplete 








EXCEPTION: In parallel to the events 
described in steps 3 to 5 the steps specified in 
Table 8.3.1 .10.3.2-2 should take place. 












EXCEPTION: In parallel to the events 
described in steps 3 to 5 the steps specified in 
Table 8.3.1 .1 0.3.2-3 should take place. 










3 


Wait for 30 s to ensure that the UE performs a 
periodical intra frequency reporting and a 
periodical inter frequency reporting. 










4 


The SS transmits an 

RRCConnectionReconfiguration message 
without an IE measurementConfiguration, to 
order the UE to perform Inter frequency 
handover to Cell 3. 


<— 


RRCConnectionReconfiguration 






5 


Check: Does the UE transmit an 
RRCConnectionReconfigurationComplete 
message to Cell 3? 


— > 


RRCConnectionReconfigurationC 
omplete 


1 


P 


6 


Check: Does the UE transmit a 
l\/leasurementReport message to perform 
periodical intra frequency reporting for Cell 6. 


— > 


IVIeasurementReport 


1 


P 


7 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 3? 






1 
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Table 8.3.1.10.3.2-2: Parallel behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: The step 1 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


The UE transmits a MeasurementReport 
message to perform periodical intra frequency 
reporting for Cell 2 and Cell 4. 


— > 


MeasurementReport 






Table 8.3.1.10.3.2-3: Parallel behaviour 


St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 




EXCEPTION: The step 1 shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


The UE transmits a MeasurementReport 
message to perform periodical inter frequency 
reporting for Cell 3 and Cell 6. 


— > 


MeasurementReport 







8.3.1 .1 0.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 

Table 8.3.1.10.3.3-1: RRCConnectionReconfiguration (step 1, Table 8.3.1.10.3.2-1) 

FFS 

Table 8.3.1.10.3.3-2: RRCConnectionReconfigurationComplete (step 2 and step 5, Table 8.3.1.10.3.2- 

1) 

FFS 

Table 8.3.1.10.3.3-3: RRCConnectionReconfiguration (step 4, Table 8.3.1.10.3.2-1) 

FFS 

Table 8.3.1.10.3.3-4: MeasurementReport (step 6, Table 8.3.1.10.3.2-1) 

FFS 

Table 8.3.1.10.3.3-5: MeasurementReport (step 1, Table 8.3.1.10.3.2-2) 

FFS 

Table 8.3.1.10.3.3-6: MeasurementReport (step 1, Table 8.3.1.10.3.2-3) 

FFS 

8.3.2 Inter RAT measurements 

8.3.2.3 Measurement configuration control and reporting / inter RAT measurements: 

event B2 (measurement of UTRAN cells) 

Editor's Note: This section is based on 36.331 v8.2.0 i.e. after RAN#40 + R2-083795. 
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8.3.2.3.1 Test Purpose (TP) 
(1) 

with { UE having completed the radio bearer establishment, initial security activation procedure and 
performed the inter RAT measurement for UTRA cell and not detected entering condition for the event 
B2 is met } 
ensure that { 

when { UE detects entering condition for the event B2 is not met } 
then { UE does not transmit any MeasurementJ^eport } 
} 

(2) 

with { UE having completed the radio bearer establishment, initial security activation procedure and 
performed the inter RAT measurement for UTRA cell and not detected entering condition for the event 
B2 is met } 
ensure that { 

when { UE detects entering condition for the event B2 is met } 
then { UE transmits a MeasurementReport } 
} 

(3) 

with { UE having completed the radio bearer establishment, initial security activation procedure and 
performed the inter RAT measurement for UTRA cell and detected entering condition for the event B2 
is met } 
ensure that { 

when { UE detects leaving condition for the event B2 is met } 
then { UE does not transmit any MeasurementJ^eport } 
} 

8.3.2.3.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.5.4.1, 
5.5.4.8 and 5.5.5. 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measMList within VarMeasurementConfiguration: 

2> if the entry condition applicable for this event, i.e. the event corresponding with the eventid of the 
corresponding reportConfig within VarMeasurementConfiguration, is fulfilled for one or more cells 
applicable for this event for a duration exceeding the value of timeToTrigger defined for this event within the 
VarMeasurementConfiguration 

3> if the reportlnterval defined within the VarMeasurementConfiguration for this event is not equal to 0: 

4> set the periodicalReportingOngoing defined within the VarEventsTriggered for this event to TRUE; 

3> set the numberOfReportsSent defined within the VarEventsTriggered for this event to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarEventsTriggered for this 
event, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the reportlnterval defined within the VarMeasurementConfiguration for this event is not equal to 0: 

4> set the periodicalReportingOngoing defined within the VarEventsTriggered for this event to TRUE; 

3> set the numberOfReportsSent defined within the VarEventsTriggered for this event to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarEventsTriggered for this 
event, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.4; 
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2> Upon expiry of the periodical reporting timer for this: 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the leaving condition applicable for this event is fulfilled for one or more of the cells included in the 

cellsToReportList defined within the VarEventsTriggered for this event for a duration exceeding the value of 
timeToTrigger defined within the VarMeasurementConfiguration for this event: 

3> remove the concerned cell(s) in the cellsToReportList defined within the VarEventsTriggered for this 
event; 

[TS 36.331, clause 5.5.4.8] 

The UE shall: 

1> for UTRA and CDMA2000, only trigger the event for cells included in the corresponding measurement object; 

1> apply equation B2-1 and equation B2-2 i.e. both have to be fulfilled, as specified below, as the entry equation for 
this event; 

1> apply equation B3-3 and equation B2-4 i.e. at least one of the two has to be fulfilled, as specified below, as the 
leaving equation for this event; 

Equation B2-1 (Entering condition 1) 

Ms - Hys < Threshl 

Equation B2-2 (Entering condition 2) 

Mn + Ofn - Hys > Threshl 

Equation B2-3 (Leaving condition 1) 

Ms + Hys > Threshl 

Equation B2-4 (Leaving condition 2) 

Mn + Ofn + Hys < Threshl 

The variables in the formula are defined as follows: 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Mn is the measurement result of the neighbouring inter RAT cell. 

Ofn is the frequency specific offset of the frequency of the neighbour cell 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Threshl is the threshold parameter for this event (i.e. b2-Thresholdl as defined within the 
VarMeasurementConfiguration for this event) 

Thresh2 is the threshold parameter for this event (i.e. b2-Threshold2 as defined within the 
VarMeasurementConfiguration for this event) 

Mn, Ms are expressed in dBm 

Ofn, Hys, Threshl, Thresh2 are expressed in dB 

[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 
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1> set the mobilityMeasResiilts to include all cells included in the cellsToReportList as defined within the 
VarEventsTriggered for this event 

1> for each included cell include the measured results in accordance with the reportConfigList defined in variable 
VarMeasurementConfiguration for that measurement; 

1> include the cells in order of decreasing reportingQuantity, i.e. the best cell is included first. 

Editor's note: It is FFS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 

1> increment the numberOfReportsSent as defined within the VarEventsTriggered for this event by 1; 

1> if the periodicalReportingOngoing defined within the VarEventsTriggered for this event is set to FALSE or 

1> if the numberOfReportsSent as defined within the VarEventsTriggered for this event is equal to reportAmount as 
defined within the reporting configuration for this event as defined in variable VarMeasurementConfiguration: 

2> set the periodicalReportingOngoing defined within the VarEventsTriggered for this event to FALSE; 

1> else: 

2> start a timer with the value of reportlnterval as defined within the VarMeasurementConfiguration for this 
event; 

1> if the measured results are for CDMA: 

2> set the preRegistrationStatus to the UE's cdma upper layer's HRPD preRegistrationStatus; 

l> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 

Editor's note: It is FFS if, for the case of a SON report of the strongest cell(s) on the carrier, the UE is required to 
report more than one cell. 

8.3.2.3.3 Test description 

8.3.2.3.3.1 Pre-test conditions 

System Simulator: 

- Cell 1, Cell 7(FFS), Cell 8(FFS), Cell 9(FFS) 

Editor's Note: It is necessary to add three UTRA cells to TS 36.508. 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell 1. 
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8.3.2.3.3.2 



Test procedure sequence 



Table 8.3.2.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits an 

RRCConnectionReconfiguration message to 
setup inter RAT measurement. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RRCConnectionReconfigurationComplete 
message to confirm the setup of inter RAT 
measurement. 


— > 


RRCConnectionReconfigurationC 
omplete 






3 


Checl<: Does the UE transmit a 
MeasurementReport message to report the 
event B2 within the time indicated in the IE 
timeToTrigger. 


— > 


MeasurementReport 


1 


F 


4 


The SS changes Cell 7 and Cell 8 parameters 
so that the measurement reporting criteria is 
met. 










5 


Checl<: Does the UE transmit a 
MeasurementReport message to report the 
event B2 for Cell 7 and Cell 8. 


— > 


MeasurementReport 


2 


P 


6 


The SS changes Cell 7 and Cell 8 parameters 
so that the measurement reporting criteria is 
not met. 










7 


Check: Does the UE transmit a 
MeasurementReport message to report the 
event B2 for Cell 7 and Cell 8 within the time 
indicated In the IE timeToTrigger 


— > 


MeasurementReport 


3 


F 


8 


Check: Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
RRC CONNECTED state on Cell 1? 






? 





8.3.2.3.3.3 Specific message contents 

Editor's Note: To be updated according to agreed RRC message structure. 

Table 8.3.2.3.3.3-1 : RRCConnectionReconfiguration (step 1, Table 8.3.2.3.3.2-1) 

FFS 

Table 8.3.2.3.3.3-2: RRCConnectionReconfigurationComplete (step 2, Table 8.3.2.3.3.2-1) 

FFS 

Table 8.3.2.3.3.3-3: MeasurementReport (step 5, Table 8.3.2.3.3.2-1) 

FFS 

8.3.2.4 Measurement configuration control and reporting / inter RAT measurements: 

Periodic reporting (measurement of UTRAN cells) 



8.3.2.4.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state and measurement configured for periodic reporting of UTRA 
cells } 
ensure that { 

when { The UE receives reference signal power for cells on the UTRA frequency where measurements 
are configured } 

then { UE sends MeasurementReport message at regular intervals for these UTRA cells } 



ETSI 



3GPP TS 36.523-1 version 8.0.1 Release 8 384 ETSI TS 136 523-1 V8.0.1 (2009-01) 

(2) 

with { UE in E-UTRA RRC_CONNECTED state and a Measurement Report message for a configured periodic 
measurement reporting of UTRA cells on a configured frequency were sent } 
ensure that { 

when { A previously reported cell become unavailable or the UE receives reference signal power on 
a reported UTRA frequency for a cell which was previously not reported } 

then { UE sends Measurement J?eport message at regular intervals for the available UTRA cells } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state and periodic measurement reporting of UTRA cells ongoing} 
ensure that { 

when { The UE receives a RRCConnectionReconfiguration message removing the measID of periodic 
reporting of UTRA cells } 

then { UE stops sending MeasurementReport message for UTRA cells } 
} 

8.3.2.4.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 36.331, clauses 5.3.5.3, 
5.5.2.2, 5.5.4.1 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobility Controllnformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> If ihQ RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.2.2] 

The UE shall: 

1> for each measid value included in the measMToRemoveList: 

2> remove the entry, from the parameter measIdList within VarMeasurementConfiguration, with the 
corresponding measid value; 

2> remove the entry within the VarMeasurementReports for this measid, if included; 

Editors note It has been agreed that the UE should NOT autonomously delete any unused measurement objects or 
reporting configurations. 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measIdList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of 
frequencies (GERAN) to be applicable as follows: 

3> if the corresponding measObject concerns UTRA or CDMA2000: when the concerned cell is included in 
the cellsToAddModifyList defined within the VarMeasurementConfiguration for this measid (i.e. the cell 
is included in the white-list); 

3> if the corresponding measObject concerns GERAN: when the concerned cell matches the ncc-Permitted 
defined within the VarMeasurementConfiguration for this measid; 

3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
blackListedCellsToAddModijyList defined within the VarMeasurementConfiguration for this measid; 
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2> else consider a neighbouring cell on the associated frequency to be applicable as follows: 

3> if the corresponding measObject concerns UTRA or CDMA2000: when the concerned cell is included in 
the cellsToAddModifyList defined within the VarMeasurementConfiguration for this measid (i.e. the cell 
is included in the white-list) or the corresponding reportingConfig includes a purpose set to 
'reportStrongestCellsForSON' or to 'reportCGF; 

3> if the corresponding measObject concerns GERAN: when the concerned cell matches the ncc-Permitted 
defined within the VarMeasurementConfiguration for this measid or the corresponding reportingConfig 
includes a purpose set to 'reportStrongestCellsForSON' or to 'reportCGF; 

3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
MackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration or: 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> if the VarMeasurementReports does not include an entry for this measid: 

4> include an entry within the VarMeasurementReports for this measid; 

4> set the numberOfiieportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsToReportList defined within the VarMeasurementReports for this 
measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> if the triggerType is set to 'periodical': 

4> clear the cellsToReportList defined within the VarMeasurementReports for this measid and include 
the applicable cell(s) in the cellsToReportList; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 



[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> set the mobilityMeasResults to include all cells included in the cellsToReportList as defined within the 
VarMeasurementReports for this measid 

1> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, ordered as follows: 

2> If for E-UTRA the reportQuantity is set as 'both' : 

3> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 
2> else: 

3> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 

Editor's note: It is FFS whether, if multiple cells meet the criteria, ordering is also applied irrespective of the cells 
carrier frequency 
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1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid by 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than to 
reportAmount as defined within the reporting configuration for this event as defined in variable 
VarMeasurementConfiguration: 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 

1> if the measured results are for CDMA: 

2> set the preRegistrationStatus to the UE's cdma upper layer's HRPD preRegistrationStatus; 

1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS which additional cells may be included in a report, e.g. cells of another type (e.g. best inter- 
frequency cell included in an intra-frequency report. 

Editor's note: It is FFS if, for the case of a SON report of the strongest cell(s) on the carrier, the UE is required to 
report more than one cell. 



8.3.2.4.3 
8.3.2.4.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1, Cell 7(FFS) and Cell 8(FFS) 

Editor's Note: It is necessary to add a cell on using frequency f2 to TS 36.508. 

UE: 

None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell 1. 



8.3.2.4.3.2 



Test procedure sequence 



Table 8.3.2.4.3.2-1 illustrates the downlink power levels to be applied for the cells at various time instants of the test 
execution. Row marked "TO" denotes the initial conditions, while rows marked "Tl" and "T2" are to be applied 
subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 

Table 8.3.2.4.3.2-1 : Power levels 





Parameter Unit Cell 1 


Parameter | Unit | Cell 7 


Cells 


Remark 




E-UTRA Cell 


UTRA Cells 




TO 


Ro 


dBm 


P01 
(FFS) 


CPICH Ec 


dBm/ 
3.84 
MHz 


P07 
(FFS) 


Off 


Power levels shall be such that 
camping on Cell 1 is guaranteed 


T1 


P01 
(FFS) 


P07 
(FFS) 


P07 
(FFS) 




T2 


P01 
(FFS) 


Off 


P07 
(FFS) 
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Table 8.3.2.4.3.2-2: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
measurements and periodical reporting for 
UTRA cells. 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
omplete 








EXCEPTION: In parallel to events described in 
steps 3 to 4 the steps specified in table 
8.3.2.4.3.2.-3 shall take place 










3 


Wait for 30 s to ensure that the UE performs a 
periodical reporting of UTRA cells. 


- 


- 


1 


- 


4 


SS sets the cell-specific reference signal levels 
and switches Cell 8 on according to row "T1" in 
table 8.3.2.4.3.2.-1. 










5 


Wait and ignore MeasurementReport 
messages for 5 s to allow for the switching of 
cells. 












EXCEPTION: In parallel to events described in 
steps 6 to 7 the steps specified in table 
8.3.2.4.3.2.-4 shall take place 










6 


Wait for 30 s to ensure that the UE performs a 
periodical reporting of UTRA cells. 


- 


- 


1,2 


- 


7 


SS sets the cell-specific reference signal levels 
and switches Cell 7 off according to row "T2" in 
table 8.3.2.4.3.2.-1. 










8 


Wait and ignore MeasurementReport 
messages for 5 s to allow for the switching of 
cells. 












EXCEPTION: In parallel to events described in 
steps 9 to 10 the steps specified in table 
8.3.2.4.3.2.-5 shall take place 










9 


Wait for 30 s to ensure that the UE performs a 
periodical reporting of UTRA cells. 


- 


- 


1,2 


- 


10 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to 
remove measid for periodic reporting. 


<— 


RRCConnectionReconfiguration 






11 


The UE transmits an 

RCConnectionReconfigrationCompiete 

message 


— > 


RRCConnectionReconfigurationC 
omplete 







Table 8.3.2.4.3.2-3: Parallel behaviour 



St 



Procedure 



U-S 



Message Sequence 



Message 



TP 



Verdict 



EXCEPTION: After the 1st message is 
received, step 1 below shall be repeated every 
time the duration indicated in the IE 
reportlntervai has elapsed. 



Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 7? 



MeasurementReport 
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Table 8.3.2.4.3.2-4: Parallel behaviour 



St 


Procedure 


■message Sequence 


TP 


Verdict 


U-S 


■message 




EXCEPTION: Step 1 below shall be repeated 
every time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 7 
and Cell 8? 


— > 


MeasurementReport 


1,2 


P 



Table 8.3.2.4.3.2-5: Parallel behaviour 



St 


Procedure 


■message Sequence 


TP 


Verdict 


U-S 


■message 




EXCEPTION: Step 1 shall be repeated every 
time the duration indicated in the IE 
reportlnterval has elapsed. 










1 


Check: Does the UE transmit a 
MeasurementReport message to perform 
periodical intra frequency reporting for Cell 8? 


— > 


MeasurementReport 


1,2 


P 



Editor's note: The value and tolerance of the reportlnterval is FFS. 



8.3.2.4.3.3 



Specific message contents 



Editors note: When default message contents of RRCConnectionReconfiguration in TS36.508 will cover 

measurement configuration the tables for specific message contents below will be updated accordingly. 
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Table 8.3.2.4.3.3-1 RRCConnectionReconfiguration (step 1, Table 8.3.2.4.3.2-2) 



Derivation path: 36.508 table table 4.6.1-6 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








rrcConnectionReconfiguration-r8 SEOUENCE { 








measurementConfiguration ::= SEQUENCE { 








measObjectToAddl\/lodifyList::= SEQUENCE 


1 entry 






(SIZE (1 ..maxObjectld)) OF SEQUENCE { 








measObjectld[1] 


IVIeasObjectld-M01 






measObject[1] 


IVIeasQbjectUTRA-M01 


UTRA frequency 




1 

reportConfigToAddlVlodifyLJst ::= SEQUENCE 


1 entry 






(SIZE (L.maxReportConfigld)) OF SEQUENCE { 








reportConfigld[1] 


ReportConfigld-RC1 






reportConfig[1] 
1 


ReportConfiglnterRAT- 
RC1 






measldToAddModifyLlst ::= SEQUENCE (SIZE 


1 entry 






(1 ..maxMeasId)) OF SEQUENCE { 








measld[1] 


1 






measObjectld[1] 


IVIeasObjectld-M01 






reportConfigld[1] 
1 


ReportConfigld-RC1 






quantityConfig ::= SEQUENCE { 








quantityConfigEUTRA 








filterCoefficient 
1 


FFS 






i 

measGapConfig ::= SEQUENCE { 








gapActivation CHOICE { 








activate SEQUENCE { 








gapPattern ENUMERATED {} 


gp1 (FFS) 






startSFN 


FFS 






startSubfranneNumber 
} 
} 
} 


FFS 






} 
} 
} 
} 

measObjectUTRA ::= SEQUENCE { 


IVIeasObjectUTRA-M01 






utra-CarrierFreq SEQUENCE {}, 


FFS 


UTRA DL carrier 
frequency 




offsetFreq 


OdB 


Default 
Neighbour cell list 




cellsToRemoveLlst 


Not present 






cellsToAddModifyList CHOICE { 








cellsToAddModifyListUTRA-FDD ::= SEQUENCE 








(SIZE (1 ..maxCellMeas)) OF SEOUENCE { 








celllndex[1] 


1 


Cell? 




cellldentity[1] 


UTRA-FDD-Cellldentity- 
UC1 (FFS) 






celllndex[2] 


2 


Cells 




cellldentity[2] 


UTRA-FDD-Cellldentity- 






} 


UC2 (FFS) 






} 
cellForWhichToReportCGI 


Not present 
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reportConfiglnterRAT ::= SEQUENCE { 

triggerType CHOICE { 
periodical SEQUENCE { 
purpose CHOICE { 

reportStrongestCells 
} 
} 
} 

maxReportCells 
reportlnterval SEQUENCE {} 

reportAmount SEQUENCE {} 

} 


ReportConfiglnterRAT- 
RC1 

2 

FFS seconds 

Not present 


Report Cell 7 and 
Cells 
Periodical 
reporting required 





Table 8.3.2.4.3.3-2 RRCConnectionReconfiguration (step 10, Table 8.3.2.4.3.2-2) 



Derivation path: 36.508 table 4.6.1-6 


Information Element 


Value/Remark 


Comment 


Condition 


RRCConnectionReconfiguration ::= SEQUENCE { 
criticalExtensions CHOICE { 
c1 CHOICE! 
rrcConnectionReconfiguration-r8 SEQUENCE { 
measurementConfiguration ::= SEQUENCE { 
measldToRemoveList::= SEQUENCE (SIZE 
(1 ..maxMeasId)) OF SEQUENCE { 
measld[1] 
} 
} 
} 
} 
} 
} 


1 entry 

1 
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Table 8.3.2.4.3.3-3 MeasurementReport (step 1, Table 8.3.2.4.3.2-3, Table 8.3.2.4.3.2-4, Table 

8.3.2.4.3.2-5) 



Derivation path: 36.508 table 4.6.1-3 | 


Information Element 


Value/Remark 


Comment 


Condition 


measuredResults ::= SEQUENCE { 








measid 


1 






measuredResultServing ::= SEQUENCE {} 




FFS 




mobilitylVleasResults CHQICE { 








measResultLlstUTRA ::= SEQUENCE (SIZE 






Table 


(1..maxCellReport)) OF SEQUENCE { 






8.3.2.4.3.2- 
3 


utra-Cellldentity[1] CHOICE { 






cellldentityFDD 


7 (FFS) 


Report Cell 7 


FDD 


cellldentityTDD 
1 


FFS 


FFS 


TDD 


measResultUTRA[1] ::= SEQUENCE {} 

} 


cpich-RSCP (FFS) 


FFS 




mobilitylVleasResults CHQICE { 








measResultLlstUTRA ::= SEQUENCE (SIZE 






Table 


(1..maxCellReport)) OF SEQUENCE { 






8.3.2.4.3.2- 

A 


utra-Cellldentity[1] CHOICE { 






M- 


cellldentityFDD 


7 (FFS) 


Report Cell 7 


FDD 


cellldentityTDD 
1 


FFS 


FFS 


TDD 


measResultUTRA[1] ::= SEQUENCE {} 


cpich-RSCP (FFS) 


FFS 




utra-Cellldentity[2] CHOICE { 








cellldentityFDD 


8 (FFS) 


Report Cell 8 


FDD 


cellldentityTDD 
1 


FFS 


FFS 


TDD 


measResultUTRA[2] ::= SEQUENCE {} 

} 


cpich-RSCP (FFS) 


FFS 




mobilitylVleasResults CHQICE { 








measResultLlstUTRA ::= SEQUENCE (SIZE 






Table 


(1..maxCellReport)) OF SEQUENCE { 






8.3.2.4.3.2- 
5 


utra-Cellldentity[1] CHOICE! 






cellldentityFDD 


8 (FFS) 


Report Cell 8 


FDD 


cellldentityTDD 
1 


FFS 


FFS 


TDD 


measResultUTRA[1] ::= SEQUENCE {} 

} 


cpich-RSCP (FFS) 


FFS 





8.3.3 Measurements for Self Optimized Networks 

8.3.3.1 Measurement configuration control and reporting / SON / ANR: CGI reporting 

of LTE cell 

Editor's Note: This section is based on 36.331 v8.3.0 i.e. after RP#41 + R2-085978. 



8.3.3.1.1 
(1) 



Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { Neighbour becomes offset better than serving 
then { UE sends MeasurementReport for event A3 } 
} 

(2) 

with I UE in E-UTRA RRC CONNECTED state 1 
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ensure that { 

when { UE is commanded to report the global cell identity of the neighbour cell } 
then { UE determines the global cell identity of the cell included in the associated measurement 
object by acquiring the relevant system information from the concerned cell and reports the global 
cell identity in the MeasurementReport } 
} 

8.3.3.1.2 Conformance requirements 

References: The conformance requirements covered in tlie current TC are specified in: TS 36.331, clauses 5.3.5.3, 5.5.3, 
5.5.4.1, 5.5.4.4 and 5.5.5. 

[TS 36.331, clause 5.3.5.3] 

If the RRCConnectionReconfiguration message does not include the mobility Controllnformation and the UE is able to 
comply with the configuration included in this message, the UE shall: 



1> If the RRCConnectionReconfiguration message includes the measurementConfiguration: 
2> perform the Measurement configuration procedure as specified in 5.5.2; 

[TS 36.331, clause 5.5.3] 

The UE supports measurement using a reporting configuration with the purpose set to 'reportCGP, if the network 
provides sufficient idle periods. 

The UE shall: 

1> for each measid included in the measldList within VarMeasurementConfiguration: 

2> If measurement gaps are active or 

2> the UE does not require measurement gaps to perform the concerned measurement: 

3> If s-Measure is not configured or 

3> If s-Measure is configured and the serving cell quality (RSRP value) is lower than this value: 

4> Perform the corresponding measurements of neighbouring cells on the frequencies and RATs 
indicated in the concerned measObject and 

4> Perform the evaluation of reporting criteria as specified in section 5.5.4; 

1> If a measurement is configured which the UE should attempt to perform during idle periods: 

2> if for one of the measurements purpose within the reportConfig is set to 'reportCGP and 

2> if timer T321 is running: 

3> determine the global cell identity of the cell included in the associated measurement object by acquiring 
the relevant system information from the concerned cell; 

[TS 36.331, clause 5.5.4.1] 

The UE shall: 

1> for each measid included in the measldList within VarMeasurementConfiguration: 

2> if the triggerType is set to 'event' consider a neighbouring cell on the associated frequency/ set of frequencies 
(GERAN) to be applicable as follows: 

3> if the corresponding measObject concerns UTRA or CDMA2000: when the concerned cell is included in 
the cellsToAddModifyList defined within the VarMeasurementConfiguration for this measid (i.e. the cell 
is included in the white-list); 
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3> if the corresponding measObject concerns GERAN: when the concerned cell matches the ncc-Permitted 
defined within the VarMeasurementConfiguration for this measid; 

3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
MackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> else consider a neighbouring cell on the associated frequency to be applicable as follows: 

3> if the corresponding measObject concerns UTRA or CDMA2000: when the concerned cell is included in 
the cellsToAddModiJyList defined within the VarMeasurementConfiguration for this measid (i.e. the cell 
is included in the white-list) or the corresponding reportingConfig includes a purpose set to 
'reportStrongestCellsForSON' or to 'reportCGV ; 

3> if the corresponding measObject concerns GERAN: when the concerned cell matches the ncc-Permitted 
defined within the VarMeasurementConfiguration for this measid or the corresponding reportingConfig 
includes a piupose set to 'reportStrongestCellsForSON' or to ' reportCGF ; 

3> if the corresponding measObject concerns EUTRA: when the concerned cell is not included in the 
MackListedCellsToAddModifyList defined within the VarMeasurementConfiguration for this measid; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells for a duration exceeding the value of timeToTrigger defined for this 
event within the VarMeasurementConfiguration while the VarMeasurementReports does not include an entry 
for this measid (a first cell triggers the event): 

3> include an entry within the VarMeasurementReports for this measid; 

3> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for 
this measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'periodical' and a (first) measurement result is available: 

3> include an entry within the VarMeasurementReports for this measid; 

3> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'event' and if the entry condition applicable for this event, i.e. the event 

corresponding with the eventid of the corresponding reportConfig within VarMeasurementConfiguration, is 
fulfilled for one or more applicable cells not included in the cellsTriggeredList for a duration exceeding the 
value of timeToTrigger defined for this event within the VarMeasurementConfiguration (a subsequent cell 
triggers the event): 

3> set the numberOJReportsSent defined within the VarMeasurementReports for this measid to 0; 

3> include the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for 
this measid, if not included; 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> Upon expiry of the periodical reporting timer for this: 

3> initiate the measurement reporting procedure, as specified in 5.5.5; 

2> if the triggerType is set to 'event' and if the leaving condition applicable for this event is fulfilled for one or 
more of the cells included in the cellsTriggeredList defined within the VarMeasurementReports for this 
measid for a duration exceeding the value of timeToTrigger defined within the 
VarMeasurementConfiguration for this event: 
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3> remove the concerned cell(s) in the cellsTriggeredList defined within the VarMeasurementReports for 
this measid; 

3> if the cellsTriggeredList defined within the VarMeasurementReports for this measid is empty: 

4> remove the entry within the VarMeasurementReports for this measid; 

4> stop the periodical reporting timer for this event, if running; 

[TS 36.331, clause 5.5.4.4] 

The UE shall: 

1> apply inequality A3-1, as specified below, as the entry condition for this event; 

1> apply inequality A3 -2, as specified below, as the leaving condition for this event; 

Inequality A3-1 (Entering condition) 

Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off' 

Inequality A3-2 (Leaving condition) 

Mn + Ofn + Ocn + Hys < Ms + Ofs + Ocs + Off 

The variables in the formula are defined as follows: 

Mn is the measurement result of the neighbouring cell. 

Ofn is the frequency specific offset of the frequency of the neighbour cell (equals Ofs for intra-frequency 

measurements and is included in MeasObjectEUTRA corresponding to the inter frequency as offsetFreq for inter- 
frequency measurements) 

Ocn is the cell specific offset of the neighbour cell. If not configured zero offset shall be applied (included in 
MeasObjectEUTRA of the serving frequency as parameter celllndividualOffset for intra-f measurements and 
included in MeasObjectEUTRA corresponding to the inter frequency as parameter celllndividualOffset for inter- 
frequency measurements). 

Ms is the measurement result of the serving cell, not taking into account any cell individual offset. 

Ofs is the frequency specific offset of the serving frequency (i.e. offsetFreq within ih& MeasObjectEUTRA 
corresponding to the serving frequency) 

Ocs is the cell specific offset of the serving cell (included in MeasObjectEUTRA of the serving frequency as 
parameter celllndividualOffset) 

Hys is the hysteresis parameter for this event (i.e. hysteresis as defined within the VarMeasurementConfiguration 
for this event) 

Off is the offset parameter for this event (i.e. a3-0ffset as defined within the VarMeasurementConfiguration for this 
event) 

Mn, Ms are expressed in dBm in case of RSRP, or in dB in case of RSRQ 

Ofn, Ocn, Ofs, Ocs, Hys, Offsxt expressed in dB 

[TS 36.331, clause 5.5.5] 

For the measid for which the measurement reporting procedure was triggered, the UE shall set the measuredResults 
within the MeasurementReport message as follows: 

1> set the IE measid to the measurement identity that triggered the measurement reporting; 

1> if the triggerType is set to 'evenf: 

2> set the neighbouringMeasResults to include all cells included in the cellsTriggeredList as defined within the 
VarMeasurementReports for this measid 
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1> else: 

2> set the neighbouringMeasResults to include the appUcable cells; 

1> ordered as follows: 

2> for each included cell include the filtered measured results in accordance with the reportConfigList defined in 
variable VarMeasurementConfiguration for that measid, as follows: 

3> If for E-UTRA the reportQuantity is set as 'both': 
4> include the E-UTRA cells in order of decreasing triggerQuantity, i.e. the best cell is included first; 

3> else: 

4> include the cells in order of decreasing reportQuantity, i.e. the best cell is included first. 

1> increment the numberOfReportsSent as defined within the VarMeasurementReports for this measid hy 1; 

1> if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is less than 
reportAmount as defined within the corresponding reporting configuration as defined in variable 
VarMeasurementConfiguration: 

2> stop the periodical reporting timer, if running; 

2> start the periodical reporting timer with the value of reportlnterval as defined within the 
VarMeasurementConfiguration for this measid; 

1> else if the numberOfReportsSent as defined within the VarMeasurementReports for this measid is equal to 
reportAmount as defined within the corresponding reporting configuration as defined in variable 
VarMeasurementConfiguration: 

2> if the triggerType is set to 'periodical' : 

3> remove the entry within the VarMeasurementReports for this measid; 
1> if the measured results ai-e for CDMA HRPD: 

2> set the hrpdPreRegistrationStatus to the UE's cdma upper layer's HRPD preRegistrationStatus; 
1> if the measured results are for CDMA IxRTT: 

2> set the hrpdPreRegistrationStatus to "0'; 

1> submit the MEASUREMENT REPORT message to lower layers for transmission, upon which the procedure 
ends. 

Editor's note: It is FFS if, for the case of a SON report of the strongest cell(s) on the carrier, the UE is required to 
report more than one cell. 

8.3.3.1.3 Test description 

8.3.3.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 2 

Preamble: 

The UE is in state Generic RB Established (state 3) on Cell 1 according to [18]. 
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8.3.3.1.3.2 



Test procedure sequence 



Table 8.3.3.1.3.2-1 illustrates the downlink power levels to be applied for Cell 1 and Cell 2 at various time instants of 
the test execution. Row marked "TO" denotes the initial conditions, while row marked "Tl" is to be applied 
subsequently. The exact instants on which these values shall be applied are described in the texts in this clause. 

Table 8.3.3.1.3.2-1 : Power levels 





Parameter 


Unit 


Cein 


Cell 2 


Remark 


TO 


Ro 


dBm 


P01 (FFS) 


P02 (FFS) 


P01 and P02 shall be such that entry condition for event A3 
is not satisfied : Mn + Ofn + Ocn + Hys <Ms + Ofs + Ocs + Off 


Tl 


Ro 


dBm 


P11 (FFS) 


P12(FFS) 


P1 1 and P1 2 shall be such that entry condition for event A3 
is satisfied : Mn + Ofn + Ocn - Hys > Ms + Ofs + Ocs + Off 



Table 8.3.3.1.3.2-2: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration to setup 
intra LTE measurement and reporting for event 
A3 (intra frequency measurement). 


<— 


RRCConnectionReconfiguration 






2 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
ompiete 






3 


SS re-adjusts the cell-specific reference signal 
level according to row "T1" in table 
8.3.3.1.3.2.-1. 










4 


Check: does the UE transmit a 
MeasurementReport message to report event 
A3 with the measured RSRP value for Cell 2? 


— > 


MeasurementReport 


1 


P 


5 


SS transmits an 

RRCConnectionReconfiguration message 
including measurementConfiguration including 
reportCG/ for Cell 2 and sufficient idle periods 
for UE to acquire the relevant system 
information from Cell 2. 


<— 


RRCConnectionReconfiguration 






6 


The UE transmits an 

RCConnectionReconfigrationComplete 

message. 


— > 


RRCConnectionReconfigurationC 
ompiete 






7 


Check: does the UE transmit a 
MeasurementReport message to report 
globalCellldentityforCell2? 


-> 


MeasurementReport 


2 


P 



Editors note; When test tolerances in TS36.508 will cover measurements step 3 above will take them into account. 



8.3.3.1.3.3 



Specific message contents 



Editors note: Specific message contents will be updated when default message contents of 

RRCConnectionReconfiguration in TS36.508 will cover measurement configuration. 

Table 8.3.3.1.3.3-1 RRCConnectionReconfiguration (step 1): measurementConfiguration test specific 

information elements 

FFS 

Table 8.3.3.1.3.3-2 IVIeasurementReport {step 4): measuredResuits test specific information elements 

FFS 

Table 8.3.3.1.3.3-3 RRCConnectionReconfiguration (step 5): measurementConfiguration test specific 

information elements 

FFS 
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Table 8.3.3.1.3.3-4 MeasurementReport {step 7): measuredResults test specific information elements 

FFS 

8.4 Inter RAT Handover 

8.5 RRC Others 
8.5.1 Radio Link Failure 

8.5.1 .1 RRC Connection Re-establishment: Success (after Radio Link Failure) 

8.5.1.1.1 Test Purpose (TP) 

(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE detecting physical layer problems} 
then { UE shall start timer T310 and UE does not initiate any RRC Connection re-establishment 
procedure before expiring of timer T310} 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE detecting radio link failure on expiring of timer T310 } 
then { UE starts timer T311 and UE initiates the RRC Connection re-establishment procedure } 
} 

(3) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE sucsessfully completes the RRC Connection re-establishment procedure } 
then { UE is in E-UTRA RRC_CONNECTED state } 
} 

8.5.1.1.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in TS 36.331, clauses 5.3.7.2, 
5.3.10.1, 5.3.10.3 and 5.3.10.4. 

[TS 36.331 clause 5.3.7.2] 

The UE shall only initiate the procedure when security has been activated. The UE initiates the procedure when one of 
the following conditions is met: 

1> upon re-entry of the service area after having detected radio link failure, in accordance with 5.3. 10; or 

1> upon handover failure, in accordance with 5.3.6.3; or 

1> when lower layers detect problems, as specified in TS 36.322 [7]. 

Upon initiation of the procedure, the UE shall: 

1> reset MAC and re-establish RLC for all RBs that are established; 

1> start timer T301; 

1> initiate transmission of the RRCConnectionReestablishmentRequest message in accordance with 5.3.7.3; 
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[TS 36.331 clause 5.3.10.1] 

Upon detecting physical layer problems, the UE shall: 

The criteria for detecting physical layer problems are FFS i.e. whether RRC considers this condition to be met upon 
receiving a certain number of physical layer failure indications within a predefined time-period. 

It is FFS if a counter will be used instead of timer T3 10. 

Upon receiving a Random Access problem indication from the MAC, the UE shall: 

1> start a timer T312. 

[TS 36.331 clause 5.3.10.3] 

Upon T310 or T312 expiry, the UE detects radio link failure and shall: 
1> If security is not activated: 

2> perform the actions upon moving from RRC_CONNECTED to RRC_IDLE as specified in 5.3.11; 
1> else: 

2> stop timer T310, if running; 

2> stop timer T312, if running; 

2> start timer T3 1 1 ; 

2> select a suitable cell in accordance with the cell selection process as specified in [4]. 

[TS 36.331 clause 5.3.10.4] 

Upon selecting an E-UTRA cell while T3 1 1 is running, the UE shall: 

1> stop timer T311; 

1> initiate the Connection re-establishment procedure as specified in 5.3.7. 

NOTE This procedure applies also if the UE returns to the source cell 
The criteria for re-entry of service area, i.e. for detecting 'in service' are FFS. 

8.5.1.1.3 Test description 

8.5.1.1.3.1 Pre-test conditions 

System Simulator: 

2 cells on same E-UTRA frequency: 

Cell 1 (default parameters) serving cell 
Cell 2 (TBD parameters) intra-frequency cell 

UE: 
None. 
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Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on cell 1. 



8.5.1.1.3.2 



Test procedure sequence 



Table 8.5.1.1.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


IP 


Verdict 


U-S 


lUlessage 


1 


SS reduces DL RS TX power level of Cell 1 
below Qrxlevmin and sends erroneous 
physical layer frames so that UE is detecting 
physical layer problems on Cell 1 . 










2 


Check: Does the UE initiate an RRC 
connection re-establishment procedure on Cell 
1 or Cell 2. This is checked during the time 
T=T310. 






1 


F 


3 


Check: does the UE send RRC connection re- 
establishment message on Cell 2? 


— > 


RRCConnectionReestablishment 
Request 


2 


P 


4 


The SS transmits 
RRCConnectionReestablishment message. 


<— 


RRCConnectionReestablishment 






5 


The UE transmits 

RRCConnectionReestablishmentComplete 

message. 


— > 


RRCConnectionReestablishment 
Complete 






6 


The SS transmits an 

RRCConnectionReconfiguration message to 
resume existing radio bearer. 


<— 


RRCConnectionReconfiguration 






7 


The UE transmits a 

RRCConnectionReconfigurationComplete 

message. 


— > 


RRCConnectionReconfigurationtC 
omplete 






8 


Check: The test result of CALL generic 
procedure indicates that the UE is in E-UTRA 
RRC CONNECTED state on Cell 2. 






3 


P 



8.5.1.1.3.3 
FFS 



Specific message contents 



8.5.1.2 RRC Connection Re-establishment: End of procedure after T301 expiry (after 

Radio Link Failure) 



8.5.1.2.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE receiving a Random Access problem indication from MAC } 
then { UE shall start timer T312 and shall continue the Random Acess procedure until timer T312 
is expired } 
} 

(2) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE detecting radio link failure on expiring of timer T312 } 
then { UE starts timer T311 and UE selects a suitable cell in accordance with the cell selection 
process } 
} 

(3) 



with { UE in E-UTRA RRC_CONNECTED state 
ensure that f 
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when { UE having sent an RRCConnectionReestablishment message on starting of timer T301 } 
then { UE re-sends RRCConnectionReestablishment messages until timer T301 is expired } 
} 

(4) 

with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE having sent an RRCConnectionReestablishment message on starting of timer T301 } 
then { UE does not send any RRCConnectionReestablishment messages after timer T301 is expired } 
} 

8.5.1 .2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in TS 36.331, clauses 5.3.7.2, 
5.3.10.1, 5.3.10.3 and 5.3.10.4. The following represent an extraction of the requirements relevant to the test purpose. 

[TS 36.331 clause 5.3.7.2] 

The UE shall only initiate the procedure when security has been activated. The UE initiates the procedure when one of 
the following conditions is met: 

1> upon re-entry of the service area after having detected radio link failure, in accordance with 5.3.10; or 

1> upon handover failure, in accordance with 5.3.6.3; or 

1> when lower layers detect problems, as specified in TS 36.322 [7]. 

Upon initiation of the procedure, the UE shall: 

1> reset MAC and re-establish RLC for all RBs that are established; 



1> start timer T301; 

1> initiate transmission of the RRCConnectionReestablishmentRequest message in accordance with 5.3.7.3; 

[TS 36.331 clause 5.3.10.1] 

Upon detecting physical layer problems, the UE shall: 

1> start a timer T310. 

The criteria for detecting physical layer problems are FES i.e. whether RRC considers this condition to be met upon 
receiving a certain number of physical layer failure indications within a predefined time-period. 

It is FFS if a counter will be used instead of timer T3 10. 

Upon receiving a Random Access problem indication from the MAC, the UE shall: 

1> start a timer T312. 

[TS 36.331 clause 5.3.10.3] 

Upon T310 or T312 expiry, the UE detects radio link failure and shall: 
1> If security is not activated: 

2> perform the actions upon moving from RRC_CONNECTED to RRC_IDLE as specified in 5.3.11; 
1> else: 

2> stop timer T310, if running; 
2> stop timer T312, if running; 
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2> start timer T3 1 1 ; 

2> select a suitable cell in accordance with the cell selection process as specified in [4]. 

[TS 36.331 clause 5.3.10.4] 

Upon selecting an E-UTRA cell while T3 1 1 is running, the UE shall: 

1> stop timer T311; 

1> initiate the Connection re -establishment procedure as specified in 5.3.7. 

NOTE This procedure applies also if the UE returns to the source cell 
The criteria for re-entry of service area, i.e. for detecting 'in service' are FES. 

8.5.1.2.3 Test description 

8.5.1.2.3.1 Pre-test conditions 

System Simulator: 

2 cells on same E-UTRA frequency: 
Cell 1 (default parameters) serving cell 
Cell 2 (TBD parameters) intra-frequency cell 

UE: 
None. 

Preamble: 

The UE is brought to UE test state Generic RB Established (state 3) on cell 1 . 
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8.5.1.2.3.2 



Test procedure sequence 



Table 8.5.1.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS triggers the Random Access Resource 
procedure on tranmit of a PDCCH order 
providing Random Access Preamble. 
UE initiates the Random Access procedure 
and transmits Random Access Preambles. 










2 


SS does not respond to the Random Access 
Preambles sent by the UE until condition 
PREAMBLE TRANSMISSION COUNTER = 
PREAMBLE TRANS MAX + 1 is fulfilled. 










4 


SS sets Cell 1 to serving cell and Cell 2 to 
suitable neighbour cell (FFS). 


- 








5 


Check: UE shall transmit Random Access 
Preambles on Cell 1 and shall not perform cell 
reselection on Cell 2 until timer T31 2 is 
expired. 






1 


P 


6 


SS does not respond to the Random Access 
Preambles sent by the UE on Cell 1 in step 5. 


- 








7 


Check: The UE shall send RRC connection re- 
establishment message on Cell 2. 


— > 


RRCConnectionReestablishment 
Request 


2 


P 


8 


The SS does not respond to any 
RRCConnectionReestablishment messages 


- 








9 


Check: The UE shall send RRC connection re- 
establishment messages on Cell 2 during timer 
T3=T301. 


— > 


RRCConnectionReestabiistiment 
Request 


3 


P 


10 


Check: The UE shall not send any RRC 
connection re-establishment messages on Cell 
2 after timer T301 is expired. 






4 


P 



8.5.1.2.3.3 
FFS 



Specific message contents 



8.5.1 .3 RRC Connection Re-establisment; Failure: T31 1 Expiry (after Radio Link 

Failure) 



8.5.1.3.1 



Test Purpose (TP) 



(1) 

with { UE in E-UTRA RRC_CONNECTED state with default bearer established and radio link failure was 
detected and UE attempts to select a suitable E-UTRA cell to re-establish the RRC connection } 
ensure that { 

when { UE can not find a suitable cell for T311 } 

then { UE does not try to re-establish the RRC connection and goes to RRC_IDLE } 



8.5.1.3.2 



Conformance requirements 



The conformance requirements covererd in the current test case are specifed in TS 36.331 clause 5.3.7.2, 5.3.7.7 and 
5.3.12. 

[TS 36.331 clause 5.3.7.2] 



Upon initiation of the procedure, the UE shall: 
1> stop timer T310, if running; 
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[TS 36.331 clause 5.3.7.7] 

Upon T31 1 expiry, the UE shall: 

1> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 

Editor's note: It is up to upper layers to take further action. To facilitate this, the cause of the release may need to be 
indicated to upper layers. 

[TS 36.331 clause 5.3.12] 

Upon moving from RRC_CONNECTED to RRC_1DLE, the UE shall: 

1> release all radio resources; 

1> indicate the release of the RRC connection to upper layers; 

1> enter RRC IDLE. 



8.5.1.3.3 


Test description 


8.5.1.3.3.1 


Pre-test conditions 


System simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB established according to [18]. 



8.5.1.3.3.2 



Test procedure sequence 



Table 8.5.1.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


lUlessage 


1 


The SS drops Cell 1 DL RS TX power level 
below Qrxlevmin and sends erroneous 
physical layer frames to the UE during T310. 










2 


The SS waits for T31 1 and then raises Cell 1 
DL RS TX power level to the original level. 


- 


- 


- 


- 


3 


Check: does the UE transmit a 
RRCConnectionReestablishmentRequest 
messages within the next 60s? 


— > 


RRCConnectionReestablishment 
Request 




F 


4 


No action (the test is successful unless it failed 
in the step 3). 


- 


- 




P 



Note: The RRC_IDLE state is not checked because the UE may have started to scan other frequencies, bands or 
RATs during the out of coverage period in step 2, so it can not be ensured that it will respond to paging. 
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8.5.1 .3.3.3 Specific message contents 

None. 

8.5.1 .4 RRC Connection Re-establisment; Failure: Reject (after Radio Link Failure) 

8.5.1 .4.1 Test Purpose (TP) 
(1) 

with { UE in E-UTRA RRC_CONNECTED state with default bearer established and radio link failure was 
detected and UE initiates the re-establishment procedure} 
ensure that { 

when { the UE receives a RRCConnectionReestablishmentReject message } 
then { UE goes to RRC_IDLE } 
} 

8.5.1.4.2 Conformance requirements 

The conformance requirements covered in the current test case are specified in TS 36.331 clause 5.3.7.9 and 5.3.12. 

[TS 36.331 clause 5.3.7.9] 

Upon receiving the RRCConnectionReestablishmentReject message, the UE shall: 

1> perform the actions upon moving from RRC_CONNECTED to RRC_1DLE as specified in 5.3.12. 

Editor's note: It is up to upper layers to take further action. To facilitate this, the cause of the release may need to be 
indicated to upper layers. 

[TS 36.331 clause 5.3.12] 

Upon moving from RRC_CONNECTED to RRCJDLE, the UE shall: 

1> reset MAC and re-establish RLC for all RBs that are estabUshed; 

Editor's note: The above is to stop ongoing procedures e.g. random access. 

1> stop all timers that are running except T320; 

1> release all radio resources; 

1> indicate the release of the RRC connection to upper layers; 

1> enter RRC_1DLE. 



8.5.1.4.3 


Test description 


8.5.1.4.3.1 


Pre-test conditions 


System simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB established state according to [18]. 
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8.5.1.4.3.2 



Test procedure sequence 

Table 8.5.1.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS sends erroneous physical layer frames 
during T310. 


- 


- 


- 


- 


2 


UE transmits an 

RRCConnectionReestablishmentRequest 

message 


— > 


RRCConnectionRestablishmentR 
equest 






3 


The SS transmits a 

RRCConnectionReestablishmentReject 

message 


<— 


RRCConnectionReestablishment 
Reject 






4 


Check: the test result of CALL generic 
procedure indicates that UE is in E-UTRA 
RRC IDLE state. 






1 


P 



8.5.1.4.3.3 
None. 

8.5.1.5 

8.5.1.5.1 
(1) 



Specific message contents 

Radio Link Recovery while T310 is running 
Test Purpose (TP) 



with { UE in E-UTRA RRC_CONNECTED state } 
ensure that { 

when { UE detecting physical layer recovery while T310 was running } 
then { the UE resumes the RRC connection without explicit signalling 



8.5.1.5.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 36.331 clause 5.3.1 1.1 
and 5.3.11.2. 

[TS 36.331, clause 5.3.11.1] 

The UE shall: 



Upon detecting physical layer problems, the UE shall: 

1> start a timer T310. 

The criteria for detecting physical layer problems are FES i.e. whether RRC considers this condition to be met upon 
receiving a certain number of physical layer failure indications within a predefined time-period. 

It is FES if a counter will be used instead of timer T3 10. 

[TS 36.331, clause 5.3.11.2] 

Upon detecting physical layer recovery while T310 was running, the UE shall: 

1> stop timer T310. 

NOTE In this case, the UE resumes the RRC connection without explicit signalling i.e. the UE resumes the entire 
radio resource configuration. 

The criteria for detecting physical layer recovery are FES. 
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8.5.1.5.3 


Test description 


8.5.1.5.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Generic RB Established (state 3) according to [18]. 



8.5.1.5.3.2 



Test procedure sequence 



Table 8.5.1.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


SS changes the cell conditions so the UE 
detects physical failure indications. 


- 


- 






2 


SSwaitsfor 1.5s<T310s. 


- 


- 


- 


- 


3 


SS changes the cell level to default value. 


- 


- 


- 


- 


4 


SS waits for 5s. 


- 


- 


1 


P 


5 


Check: does the test result of CALL generic 
procedure indicate that UE is in E-UTRA 
RRC CONNECTED state? 






1 





8.5.1.5.3.3 



Specific message contents 

Table 8.5.1.5.3.3-1 SystenilnformationBlockType2 



Derivation path: 36.508 table 4.4.3.3-1 


Information Element 


Value/Remark 


Comment 


Condition 


SystemlnformationBlockType2 ::= SEQUENCE { 








ue-TimersAndConstants { 








t310 


ms2000 







8.5.4 UE capability transfer 



UE capability transfer / Success 
Test Purpose (TP) 



8.5.4.1 

8.5.4.1.1 
(1) 

with { UE in RRC_CONNECTED state } 
ensure that { 

when { UE receives an UECapabilityEnquiry message } 

then { UE transmits an UECapabilitylnformation message including UE radio access capability 
information corresponding to the ue-RadioAccessCapRequest variable } 
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8.5.4.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 36.331, clause 5.6.3.3. 

[TS 36.331, clause 5.6.3.3] 

The UE shall: 

1> set the contents of UECapabilitylnformation message as follows: 

2> If the ue-RadioAccessCapRequest includes E-UTRA: 

3> include the UE-EUTRA-Capability within a ueCapabilitiesRAT-Container and with the rat-Type set to 
eutra; 

2> If the UE radio access capability request includes GERAN: 

3> include the UE radio access capabilities for GERAN within a ueCapabilitiesRAT-Container and with the 
rat-Type set to geran; 

2> If the UE radio access capability request includes UTRA: 

3> include the UE radio access capabilities for UTRA within a ueCapabilitiesRAT-Container and with the 
rat-Type set to utran; 

2> If the UE radio access capability request includes CDMA2000-lxRTT Bandclass: 

3> include the UE band class radio access capabilities for CDMA 2000 within a ueCapabilitiesRAT- 
Container and with the rat-Type set to cdmalOOO-lxrttBandClass; 

1> submit the UECapabilitylnformation message to lower layers for transmission, upon which the procedure ends. 

8.5.4.1.3 Test description 

8.5.4.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

UE: 
None. 

Preamble: 

The UE is in state Generic RB Established (state 3) according to [18] on Cell 1. 
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8.5.4.1.3.2 



Test procedure sequence 



Table 8.5.4.1.3.2-1: Main Behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits an UECapabilityEnquiry 
message to request UE radio access capability 
information for E UTRA only. 


<— 


UECapabilityEnquiry 






2 


Check: Does the UE transmit an 
UECapabilitylnformation message? 


— > 


UECapabilitylnformation 


1 


P 


- 


EXCEPTION: Steps 3a1 to 3a2 describe 
behaviour that depends on the UE capability. 


- 


- 


- 


- 


3a1 


IF pc FDD, pc TDD HCR, pc TDD LCR, 
pc_TDD_VHCR, pc_UMTS_GSM, pc_1xRTT 
or pc_HRPD THEN the SS transmits an 
UECapabilityEnquiry message to request UE 
radio access capability information for every 
other supported RATs. 


<— 


UECapabilityEnquiry 






3a2 


Check: Does the UE transmit an 
UECapabilitylnformation message? 


— > 


UECapabilitylnformation 


1 


P 



8.5.4.1 .3.3 Specific message contents 

Table 8.5.4.1.3.3-1: UECapabilityEnquiry (step 1, Table 8.5.4.1.3.2-1) 



Derivation path: 36.508 clause 4.6.1 table 4.6.1-23 


Information Element 


Value/Remark 


Comment 


Condition 


UECapabilityEnquiry ::= SEQUENCE { 
criticalExtensions CHOICE { 
c1 CHOICE! 
ueCapabilityEnquiry-r8 SEQUENCE { 
ue-RadioAccessCapRequest 
} 
} 
} 
} 


eutra 


E-UTRA only 
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Table 8.5.4.1.3.3-2: UECapabilitylnformation (step 2, Table 8.5.4.1.3.2-1) 



Derivation path: 36.508 clause 4.6.1 table 4.6.1-24 


Information Element 


Value/Remark 


Comment 


Condition 


UECapabilitylnformation ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








ueCapabilitylnformation-r8 SEQUENCE { SIZE 


1 entry only 






(1..maxRAT-Capabilities)) OF SEQUENCE { 








rat-Type[1] 


eutra 


E-UTRA only 




ueCapabilitiesRAT-Container[1 ] OCTET 








STRING { 








UE-EUTRA-Capability SEQUENCE { 








accessStratumRelease 


rel8 


Release 8 only 




ue-Category 


FFS 






pdcp- Parameters 


Not checked 






phyLayerParameters SEQUENCE { 








ul-TxDiversitySupported 


Not checked 






ue-SpecificRefSigsSupported 
1 


Not checked 






rf-Parameters SEQUENCE (SIZE 








(1 ..maxBands)) OF SEQUENCE { 








supportedEUTRA-BandList SEQUENCE { 


n entries (not checked) 


Depending of 
number of 
supported EUTRA 
bands 




eutra-Band[1..n] 


Not checked 






halfDuplex[1..n] 

} 


Not checked 






} 

measurementParameters SEQUENCE { 








eutra-BandList SEQUENCE (SIZE 








(1 ..maxBands)) OF SEQUENCE { 








interFreqEUTRA-BandList SEQUENCE 


same number of entries 






(SIZE (1 ..maxBands)) OF SEQUENCE { 


like in supportedEUTRA- 
BandList 






interFreqNeedForGaps[1 ..n] 
1 


Not checked 






InterRAT-BandLlst SEQUENCE (SIZE 


m entries (not checked) 


Depending of 


FFS 


(1 ..maxBands)) OF SEQUENCE { 




number of 
supported 
InterRAT bands 




interRAT-NeedForGaps[1 ..m] 

} 
1 


Not checked 






} 

InterRAT-Parameters SEQUENCE { 


m elements are present 






utraFDD 


Present 




pc FDD 


utraTDD128 


Present 




pc TDD L 
CR 


utraTDD384 


Present 




pc TDD H 
CR 


utraTDD768 


Present 




pc TDD V 
NCR 


geran 


Present 




pc UMTS 
GSM 


cdma2000-HRPD 


Present 




pc HRPD 


cdma2000-1xRTT 
1 


Present 




pc IxRTT 


i 

nonCritical Extension 

} 
} 
} 
} 
} 
} 


SEQUENCE {} 


Not present 
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Table 8.5.4.1.3.3-3: UEcapabilityEnquiry (step 3a1, Table 8.5.4.1.3.2-1) 



Derivation path: 36.508 clause 4.6.1 table 4.6.1-23 


Information Element 


Value/Remark 


Comment 


Condition 


UEcapabilityEnquiry ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








ueCapabilityEnquiry-r8 SEQUENCE { 


Numbering of entries is 


According to inter- 






according to conditions 


RAT capabilities 






met 


of UE 




ue-RadioAccessCapRequest[i1 ] 


utran 


This entry is 


pc FDD, 






present if the UE 


pc TDD H 






is capable of any 


CR, 






mode (FDD/TDD) 


pc TDD L 






in UMTS. 


CR, 

pc TDD V 

HCR 


ue-RadioAccessCapRequest[i2] 


geran 




pc UMTS 
GSM 


ue-RadioAccessCapRequest[l3] 


cdma2000- 




pc IxRTT, 




IxrttBandClass 




pc_HRPD 


nonCriticalExtension SEQUENCE {} 
} 
} 
} 
} 


Not present 
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Table 8.5.4.1.3.3-4: UECapabilitylnformation (step 3a2, Table 8.5.4.1.3.2-1) 



Derivation path: 36.508 clause 4.6.1 table 4.6.1-24 | 


Information Element 


Value/Remark 


Comment 


Condition 


UECapabilitylnformation ::= SEQUENCE { 








criticalExtensions CHOICE { 








c1 CHOICE! 








ueCapabilitylnformation-r8 SEQUENCE { SIZE 




Stated capability 




(1..maxRAT-Capabilities)) OF SEQUENCE { 




shall be 
compatible with 
3GPP TS 36.523- 
2(ICS 

statements) and 
the user settings 




rat-Type [11] 


utran 




pc FDD, 

pc TDD H 

CR, 

pc TDD L 

CR, 

pc TDD V 

HCR 


ueCapabilitiesRAT-Container[i1] OCTET 


FFS 


The encoding of 


pc FDD, 


STRING {} 




UE capabilities is 


pc TDD H 






defined in IE 


CR, 






[FFS] TS 25.331 


pc TDD L 






[19]. 


CR, 

pc TDD V 

HCR 


rat-Type[i2] 


geran 




pc UMTS 
GSM 


ueCapabilitiesRAT-Container [i2] OCTET 


FFS 


The encoding of 


pc UMTS 


STRING {} 




UE capabilities is 
defined in IE 
[FFS] [24.008 
and/or 44.018; 
FFS]. 


GSM 


rat-Type [13] 


cdma2000- 




pc IxRTT, 




IxrttBandClass 




pc_HRPD 


ueCapabilitiesRAT-Container [i3] OCTET 


FFS 


The encoding of 


pc IxRTT, 


STRING {} 




UE capabilities is 
defined in IE 
[A.S.0008; FFS] 


pc HRPD 


nonCriticalExtension SEQUENCE {} 
} 
} 
} 
} 


Not present 







EPS Mobility IVIanagement 

Editor's note: The contents of this section are aligned with 3GPP TS 24.301 vO.4.0. 
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9.1 EMM common procedures 
9.1 .1 GUTI reallocation procedures 

9.1 .1 .1 GUTI reallocation procedure 

9.1.1.1.1 Test Purpose (TP) 

(1) 

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode } 
ensure that { 

when { UE receives a GUTI REALLOCATION COMMAND message allocating a new GUTI and a new TAI list } 
then { UE transmits a GUTI REALLOCATION COMPLETE and UE considers the new GUTI as valid and the 
old GUTI as invalid and UE considers the new TAI list as valid and the old TAI list as invalid } 
} 

9.1 .1 .1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.4.1.1, 

5.4.1.2 and 5.4.1.3. 

[TS 24.301, clause 5.4.1.1] 

The purpose of the GUTI reallocation procedure is to allocate a GUTI and optionally to provide a new TAI list to a 
particular UE. 

The reallocation of a GUTI is performed by the unique procedure defined in this subclause. This procedure can only be 
initiated by the MME in state EMM-REGISTERED. 

The GUTI can also be implicitly reallocated at attach or tracking area updating procedures. The implicit reallocation of 
a GUTI is described in the subclauses which specify these procedures (see subclause 5.5.1 and 5.5.3). 

The PLMN identity in the GUTI indicates the current registered PLMN. 

NOTE 1 : The GUTI reallocation procedure is usually performed in ciphered mode. 

NOTE 2: Normally, the GUTI reallocation will take place in conjunction with another mobility management 
procedure, e.g. as part of tracking area updating. 

[TS 24.301, clause 5.4.1.2] 

The MME shall initiate the GUTI reallocation procedure by sending a GUTI REALLOCATION COMMAND message 
to the UE and starting the timer T3450 (see figure 5.4.1.2.1). 

The GUTI REALLOCATION COMMAND message shall include a GUTI and may include a TAI hst. 



[TS 24.301, clause 5.4.1.3] 

Upon receipt of the GUTI REALLOCATION COMMAND message, the UE shall store the GUTI and the TAI list, and 
send a GUTI REALLOCATION COMPLETE message to the MME. The UE considers the new GUTI as valid and the 
old GUTI as invalid. If the UE receives a new TAI list in the GUTI REALLOCATION COMMAND message, the UE 
shall consider the new TAI list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAI list 
as valid 

9.1.1.1.3 Test description 

9.1.1.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 and Cell 3: 
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- Cell 1 is the serving cell with TAll (PLMNl+TACl); 

- Cell 3 is a neighbour with TAI4 (PLMN1+TAC4). 

UE: 
None. 

Preamble: 

- UE in EMM-REGISTERED state / EMM-CONNECTED mode (state 2) according to [ 1 8] on cell 1 . 
Editor's note: No such state is defined, state 2 is "Registered, Idle mode". 

- The UE has a valid GUTIl and a vaHd TAIJist_l {TAU, TAI2 (PLMNl + TAC2), TAB (PLMNl + TAC3)} 
for EPS service. 



9.1.1.1.3.2 



Test procedure sequence 



Table 9.1.1.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a GUTI REALLOCATION 
COMMAND message as specified. 


<- 


GUTI REALLOCATION 
COMMAND 


- 


- 


2 


Check: Does the UE transmit a GUTI 
REALLOCATION COMPLETE as specified? 


— > 


GUTI REALLOCATION 
COMPLETE 


1 


P 


3 


The SS releases the RRC connection. 


- 


- 


- 


- 


4 


The SS transmits a Paging on cell 1 with S- 
TMSI1 


- 


- 


- 


- 


5 


Check: Does the UE perform a random access 
on cell 1 in the next 5s? 


- 


- 


1 


F 


6 


Check: Does the test results of CALL generic 
procedure [18] indicate that the UE Is in E- 
UTRA EMM-REGISTERED state on cell 1 with 
PagingUE-ldentlty = S-TMSI2? 






1 




7 


Set the cell type of cell 3 to the "Serving cell". 
Set the cell type of cell 1 to the "Suitable 
neighbour cell". 










8 


Check: Does the UE perform a random access 
on cell 3 in the next 5s? 


- 


- 


1 


F 


9 


Check: Does the test results of CALL generic 
procedure [18] indicate that the UE Is in E- 
UTRA EMM-REGISTERED state on cell 3 with 
PagingUE-ldentlty = S-TMSI2? 






1 





Note 1 : It is assumed in the test procedure sequence that the UE initially has a valid GUTI. 
Note 2: NAS security procedures are checked in this TC, especially integrity procedures. 
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9.1 .1 .1 .3.3 Specific message contents 

Table 9.2.1.1.1.3.3-1: Message GUTI REALLOCATION COMMAND (step 1, Table 9.2.1.1.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 3 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


No security 
protection 




GUTI 


GUTI2 


New GUTI 




TAI list 


present 


TAI1,TAI4 




Length of tracking area identity list contents 


00001010 


1 octets 




Partial tracking area identity list 1 




TA1 1, TAW 




Type of list 


000 


Non consecutive 
TAGS 




Number of elements 


2 






MCC 


PLMNI'sMGG 






MNC 


PLMNI'sNGG 






TAC1 


TAG1 


Gell 1 




TAG 2 


TAG4 


Gell3 





Note: This message is a SECURITY PROTECTED NAS MESSAGE with Security header type = 0001(Security 
protected NAS message). 

Table 9.2.1.1.1.3.3-2: Message GUTI REALLOCATION COMPLETE (step 2, Table 9.2.1.1.1.3.2-1) 



Derivation path: 36.508 table 4.7.3-14 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


No security 
protection 





Note: This message is a SECURITY PROTECTED NAS MESSAGE with Security header type = 0001(Security 
protected NAS message). 



9.1 .1 .2 GUTI reallocation procedure, no TAI list 

9.1.1.2.1 Test Purpose (TP) 

(1) 

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode } 
ensure that { 

when { UE receives a GUTI REALLOCATION COMMAND message allocating a new GUTI and no TAI list } 
then { UE transmits a GUTI REALLOCATION COMPLETE and UE considers the new GUTI as valid and the 
old GUTI as invalid and UE considers the old TAI list as valid } 



9.1.1.2.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.4.1.1, 
5.4.1.2 and 5.4.1.3. 

[TS 24.301, clause 5.4.1.1] 

The purpose of the GUTI reallocation procedure is to allocate a GUTI and optionally to provide a new TAI list to a 
particular UE. 

The reallocation of a GUTI is performed by the unique procedure defined in this subclause. This procedure can only be 
initiated by the MME in state EMM-REGISTERED. 

The GUTI can also be implicitly reallocated at attach or tracking area updating procedures. The implicit reallocation of 
a GUTI is described in the subclauses which specify these procedures (see subclause 5.5.1 and 5.5.3). 

The PLMN identity in the GUTI indicates the current registered PLMN. 
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NOTE 1 : The GUTI reallocation procedure is usually performed in ciphered mode. 

NOTE 2: Normally, the GUTI reallocation will take place in conjunction with another mobility management 
procedure, e.g. as part of tracking area updating. 

[TS 24.301, clause 5.4.1.2] 

The MME shall initiate the GUTI reallocation procedure by sending a GUTI REALLOCATION COMMAND message 
to the UE and starting the timer T3450 (see figure 5.4.1.2.1). 

The GUTI REALLOCATION COMMAND message shall include a GUTI and may include a TAI Ust. 



[TS 24.301, clause 5.4.1.3] 

Upon receipt of the GUTI REALLOCATION COMMAND message, the UE shall store the GUTI and the TAI list, and 
send a GUTI REALLOCATION COMPLETE message to the MME. The UE considers the new GUTI as valid and the 
old GUTI as invalid. If the UE receives a new TAI list in the GUTI REALLOCATION COMMAND message, the UE 
shall consider the new TAJ list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAJ list 
as valid 

9.1.1.2.3 Test description 

9.1.1.2.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 and Cell 3: 

- Cell 1 is the serving cell A with TAIl (PLMNl+TACl); 

- Cell 3 is a neighbour cell B with TAI3 (PLMN1+TAC3). 

UE: 
None. 

Preamble: 

- UE in EMM-REGISTERED state / EMM-CONNECTED mode (state 2) according to [18] on cell A. 
Editor's note: No such state is defined, state 2 is "Registered, Idle mode". 

- The UE has a valid GUTIl and a vaHd TAIJist_l (TAIl, TAI2 (PLMNl, TAC2), TAB } for EPS service. 
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9.1.1.2.3.2 



Test procedure sequence 



Table 9.1.1.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The SS transmits a GUTI REALLOCATION 
COIVIIVIAND message as specified. 


<— 


GUTI REALLOCATION 
COMMAND 






2 


Checl<: Does the UE transmit a GUTI 
REALLOCATION COMPLETE as specified? 


-> 


GUTI REALLOCATION 
COMPLETE 


1 


P 


3 


The SS releases the RRC connection. 


- 


- 


- 


- 


4 


The SS transmits a Paging on cell 1 with S- 
TMSI1. 


- 


- 


- 


- 


5 


Check: Does the UE perform a random access 
on cell 1 in the next 5s? 


- 


- 


1 


F 


6 


Check: Does the test results of CALL generic 
procedure indicate that the UE is in E-UTRA 
EIVIM-REGISTERED state on cell A with 
PagingUE-ldentity = S-TMSI2? 






1 




7 


Set the cell type of cell 3 to the "Serving cell". 
Set the cell type of cell 1 to the "Suitable 
neighbour cell". 










8 


Check: Does the UE perform a generic 
TRACKING AREA UPDATE procedure [18] 
indicating that the UE is in E-UTRA EIVIM- 
REGISTERED state on cell 3 with TAI3 within 
10 seconds? 






1 





Note 1 : It is assumed in the test procedure sequence that the UE initially has a valid GUTI. 
Note 2: NAS security procedures are checked in this TC, especially integrity procedures. 

9.1 .1 .2.3.3 Specific message contents 

Table 9.2.1.1.2.3.3-1: Message GUTI REALLOCATION COMMAND (step 1, Table 9.2.1.1.2.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 3 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


No security 
protection 




GUTI 


GUTI2 


New GUTI 




TAI list 


Not present 


No TAI list 





Note: This message is a SECURITY PROTECTED NAS MESSAGE with Security header type = 0001(Security 
protected NAS message). 

Table 9.2.1.1.2.3.3-2: Message GUTI REALLOCATION COMPLETE (step 2, Table 9.2.1.1.2.3.2-1) 



Derivation path: 36.508 table xxx 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


No security 
protection 





Note: This message is a SECURITY PROTECTED NAS MESSAGE with Security header type = OOOI(Security 
protected NAS message). 
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9.1.2 Authentication procedure 

9.1.2.1 Authentication accepted 

9.1.2.1.1 Test Purpose (TP) 
(1) 

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode} 
ensure that { 

when { the UE receives an AUTHENTICATION REQUEST message } 

then { the UE establishes correct EPS security context and responds with a correct 
AUTHENTICATION RESPONSE message } 
} 

9.1 .2.1 .2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.1 and 
5.4.2.33 and TS 33.401, clause 6.1.1. 

[TS 24.301, clause 5.4.2.1] 

The UE shall only support the EPS authentication challenge if a USIM is present. 

An EPS security context is established in the UE and the network when an EPS authentication is successfully 
performed. During a successful EPS authentication, the CK and IK keys are computed. CK and IK are then used as key 
material to compute a new key, KASME. KASME is stored in the EPS security contexts (see 3GPP TS 33.401 [11]) of 
both the network and the UE, and is the root for the EPS integrity protection and ciphering key hierarchy. 

[TS 24.301, clause 5.4.2.3] 

The UE shall respond to an AUTHENTICATION REQUEST message. With the exception of the cases described in 
subclause 5.4.2.6, the UE shall process the authentication challenge data and respond with an AUTHENTICATION 
RESPONSE message to the network. 

Upon a successful EPS authentication challenge, the new KASME calculated from the authentication challenge data 
shall overwrite the previous KASME. 

[TS 33.401, clause 6.1.1] 

UE shall compute KASME from CK, IK, and serving network's identity (SN id) using the KDF as specified in Annex 
A. SN id binding implicitly authenticates the serving network's identity when the derived keys from KASME are 
successfully used. 

UE shall respond with User authentication response message including RES. 

9.1.2.1.3 Test description 
9.1.2.1.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

UE: 

None. 

Preamble: 

- UE in EMM-REGISTERED state / EMM-CONNECTED mode (State 3) according to [ 1 8] . 
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Editor's note: No such state is defined, state 3 is "Generic RB established". 



9.1.2.1.3.2 



Test procedure sequence 



Table 9.1.2.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


SS transmits an AUTHENTICATION 
REQUEST message 


<— 


AUTHENTICATION REQUEST 


- 


- 


2 


Check: Does the UE respond with a correct 
AUTHENTICATION RESPONSE message 
within 6 seconds and the included RES 
matches the one stored in the SS? 


--> 


AUTHENTICATION RESPONSE 


1 


P 


3 


SS transmits a SECURITY MODE COMMAND 
message 


<— 


SECURITY MODE COMMAND 


- 


- 


4 


Check: Does the UE respond with a correct 
SECURITY MODE COMPLETE message 
integrity protected with the selected MAS 
integrity algorithm and the NAS integrity key 
based on the Kasme indicated by the KSIasme? 


— > 


SECURITY MODE COMPLETE 


1 


P 


4 


SS releases the RRC connection 


- 


- 


- 


- 


5 


SS pages the UE using S-TMSI. Paging 
Cause= Terminating High Priority Signalling 


- 


- 


- 


- 


6 


Check: Does the UE respond with a correct 
SERVICE REQUEST message providing 
KSIasme value that equals the value provided 
in the AUTHENTICATION REQUEST 
message? 


— > 


SERVICE REQUEST 


1 


P 


E 


ditor's note: This scenario is not using the new ke 


ys, whicl 


1 is not a realistic network behaviour and ma 


y cause sid 



effects. 
Editor's note: There is no requirement that the UE shall answer before 6s. 
Editor's note: The check of RES shall be introduced in default message contents in 36.508. 



9.1.2.1.3.3 
EPS. 



Specific message contents 



9.1 .2.3 Authentication not accepted by the network, GUT! used, authentication reject 

and re-authentication 



9.1.2.3.1 
(1) 



Test Purpose (TP) 



with { UE having sent an initial NAS message with type of identity GUTI } 
ensure that { 

when { as a result of failure of an Authentication procedure intiated by the network the UE 
receives an AUTHENTICATION REJECT message } 

then { the UE shall set the update status to EU3 ROAMING NOT ALLOWED, delete the stored GUTI, 
TAI list, last visited registered TAI and KSIasme and enter state EMM-DEREGISTERED } 
} 

9.1.2.3.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.5. 

[TS 24.301, clause 5.4.2.5] 

Upon receipt of an AUTHENTICATION REJECT message, the UE shall set the update status to EU3 ROAMING NOT 
ALLOWED, delete the stored GUTI, TAI list, last visited registered TAI and KSIASME. The USIM shall be 
considered invalid until switching off the UE or the UICC containing the USIM is removed. 
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If the AUTHENTICATION REJECT message is received by the UE, the UE shall abort any EMM signalling 
procedure, stop any of the timers T3410, T3417 or T3430 (if running) and enter state EMM-DEREGISTERED. 

9.1.2.3.3 Test description 

9.1.2.3.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

UE: 

- The test USIM contains a valid GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 

Preamble: 

- The UE is in state Switched OFF (state 1) according to [18]. 
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9.1.2.3.3.2 



Test procedure sequence 



Table 9.1.2.3.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Switch the UE on 


- 


- 


- 


- 


2 


The UE transmit an ATTACH REQUEST 
message including a GUTI-1 and a PDN 
CONNECTIVITY REQUEST message 


— > 


ATTACH REQUEST 






3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE. 


— > 


AUTHENTICATION RESPONSE 


- 


- 


5 


The SS transmits an AUTHENTICATION 
REJECT message 


<— 


AUTHENTICATION REJECT 


- 


- 


6 


SS releases the RRC connection 


- 


- 


- 


- 


7 


Check; Does the test result of CALL generic 
procedure indicate that the UE is in E-UTRA 
EMM-DEREGISTERED state? FFS 






1 




8 


Switch the UE off 


- 


- 


- 


- 


9 


Switch the UE on 


- 


- 


- 


- 


10 


Check: Does UE transmit an ATTACH 
REQUEST message including IMSI and a 
PDN CONNECTIVITY REQUEST message 
(Note 1)? 


— > 


ATTACH REQUEST 


1 


P 


11 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






12 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






13 


The SS transmits a NAS SECURITY MODE 
COIVIMAND message to activate NAS security. 


<— 


SECURITY MODE COMMAND 


- 


- 


14 


The UE transmits a NAS SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 






15 


SS responds with ATTACH ACCEPT message 
with a new GUTI-2 included in the EPS mobile 
identity IE 


<— 


ATTACH ACCEPT 






16 


The UE transmits an ATTACH COMPLETE 
message 


— > 


ATTACH COMPLETE 


- 


- 


Note 1 : The ATTACH REQUEST message combined with the PDN CONNECTIVITY REQUEST message shall not 
be integrity protected 



9.1.2.3.3.3 
FFS. 



Specific message contents 



9.1 .2.4 Authentication not accepted by the UE, MAC code failure 

9.1.2.4.1 Test Purpose (TP) 

(1) 

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode} 
ensure that { 

when { the UE receives an AUTHENTICATION REQUEST message with invalid MAC code } 

then { the UE shall send an AUTHENTICATION FAILURE message to the network, with the reject cause 
"MAC failure" } 
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9.1.2.4.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.4.2.6. 

[TS 24.301, clause 5.4.2.6] 

In an EPS authentication challenge, the UE shall check the authenticity of the core network by means of the AUTN 
parameter received in the AUTHENTICATION REQUEST message. This enables the UE to detect a false network. 

During an EPS authentication procedure, the UE may reject the core network due to an incorrect AUTN parameter (see 
3GPP TS 33.401 [11]). This parameter contains two possible causes for authentication failure: 

a) MAC code failure: 

If the UE finds the MAC code (supplied by the core network in the AUTN parameter) to be invalid, the UE shall 
send an AUTHENTICATION FAILURE message to the network, with the reject cause "MAC failure". The UE 
shall then follow the procedure described in subclause 5.4.2.7 (c). 

[TS 24.301, clause 5.4.2.7] 

c) Authentication failure (reject cause "MAC failure"): 

The UE shall send an AUTHENTICATION FAILURE message, with reject cause "MAC failure" according to 
subclause 5.4.2.6, to the network and start timer T3418. Furthermore, the UE shall stop any of the retransmission 
timers that are running (e.g. T3410, T3417, T3421 or T3430). Upon the first receipt of an AUTHENTICATION 
FAILURE message from the UE with reject cause "MAC failure", the network may initiate the identification 
procedure described in subclause 5.4.4. This is to allow the network to obtain the IMSI from the UE. The 
network may then check that the GUTI originally used in the authentication challenge corresponded to the 
correct IMSI. Upon receipt of the IDENTITY REQUEST message from the network, the UE shall send the 
IDENTITY RESPONSE message. 



If the GUTI/IMSI mapping in the network was incorrect, the network should respond by sending a new 
AUTHENTICATION REQUEST message to the UE. Upon receiving the new AUTHENTICATION REQUEST 
message from the network, the UE shall stop the timer T3418, if running, and then process the challenge 
information as normal. 

Test description 

Pre-test conditions 



9.1.2.4.3 




9.1.2.4.3.1 




System Simu 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

- UE in EMM-REGISTERED state / EMM-CONNECTED mode (State 3) according to [ 1 8] . 
Editor's note: No such state is defined, state 3 is "Generic RB established". 
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9.1.2.4.3.2 



Test procedure sequence 



Table 9.1.2.4.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


SS transmits an AUTHENTICATION 
REQUEST message which contains an invalid 
IVIAC code 


<— 


AUTHENTICATION REQUEST 






2 


Check: Does the UE respond with a 
AUTHENTICATION FAILURE message, with 
reject cause "MAC failure"? 


— > 


AUTHENTICATION FAILURE 


1 


P 


3 


SS transmits an IDENTITY REQUEST 
message requesting IIVISI in the IE Identity 
type 


<— 


IDENTITY REQUEST 






4 


The UE responds with a correct IDENTITY 
RESPONSE message providing its IMSI in the 
IE IVIobile Identity 


— > 


IDENTITY RESPONSE 






5 


SS transmits a correct AUTHENTICATION 
REQUEST message 


<— 


AUTHENTICATION REQUEST 


- 


- 


6 


Check: Does the UE respond with a correct 
AUTHENTICATION RESPONSE message 
with RES that matches the one stored in the 
SS? 


— > 


AUTHENTICATION RESPONSE 


1 


P 


7 


SS transmits a SECURITY MODE COMMAND 
message 


<— 


SECURITY MODE COMMAND 


- 


- 


8 


UE transmits a SECURITY MODE 
COMPLETE message integrity protected with 
the selected NAS integrity algorithm and the 
NAS integrity key based on the KASME 
indicated by the KSIASME 


— > 


SECURITY MODE COMPLETE 







9.1.2.4.3.3 
FFS. 



Specific message contents 



9.1 .3 Security mode control procedure 

9.1 .3.1 NAS security mode command accepted by the UE 



9.1.3.1.1 



(1) 



Test Purpose (TP) 



with { succesful completion of EPS authentication and key agreement (AKA) procedure } 
ensure that { 

when { UE receives an integrity protected SECURITY MODE COMMAND message including replayed 
security capabilities and IMEISV request } 

then { UE sends an integrity protected and ciphered SECURITY MODE COMPLETE message including 
IMEISV and starts applying the NAS Security in both UL and DL } 

(2) 

with { NAS Security Activated and EPS Authentication and key agreement procedure is executed for new 
Key generation} 
ensure that { 

when { UE receives an integrity protected SECURITY MODE COMMAND message corresponding to NAS count 
rest to zero including replayed security capabilities and IMEISV request } 

then { UE sends integrity protected and ciphered SECURITY MODE COMPLETE message [with NAS count 
set to zero] including IMEISV and starts applying the NAS Security in both UL and DL} 



9.1.3.1.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.2.1, 
5.4.3.1, 5.4.3.2 and 5.4.3.3. 
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Editor's note: Sections 5.4.3.1 and 5.4.3.2 seem to not contain any UE requirement. 

[TS 24.301, clause 4.4.2.1] 

The network NAS COUNT shall be initiahzed to zero in the first SECURITY MODE COMMAND when a new 
security context is activated following a successful authentication and key agreement (AKA) procedure. The UE NAS 
COUNT shall be initialized to zero when the UE receives the first SECURITY MODE COMMAND message after a 
successful AKA procedure and uses it in the following SECURITY MODE COMPLETE message. 

Editor's note: How the NAS COUNT shall be handled after handover from UTRAN/GERAN to E-UTRAN is FFS. 

After each new outbound message, the sender shall always increase the NAS COUNT number by one. Specifically, the 
NAS sequence number is increased by one, and if the result is zero (due to wrap around), the NAS overflow counter is 
also incremented by one (see 4.4.2.5). 

Editor's note: Other general details are FFS. 

[TS 24.301, clause 5.4.3.1] 

The purpose of the NAS security mode command (SMC) procedure is to take the new key set into use, initialise and 
start NAS signalling security between the UE and the MME, which performs integrity and replay protection as well as 
enciphering and deciphering of NAS signalling messages. 

Editor's note: It is FFS whether the SMC procedure can be combined or concatenated with the attach and tracking 
area update procedures for optimisation purposes. 

[TS 24.301, clause 5.4.3.2] 

The MME initiates the NAS security mode setup command procedure by sending a SECURITY MODE COMMAND 
message to the UE and starting timer T3460. 

The MME shall integrity protect the SECURITY MODE COMMAND message with the NAS integrity key based on 
Kasme indicated by the KSIasme indicated in the message. 



The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to 
NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security 
capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed NONCEUE if the UE 
included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set 
Identifier (KSIasme or KSIsgsn)- 

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message. 

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it is 
also be supported for AS. 

[TS 24.301, clause 5.4.3.3] 

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode 
command can be accepted or not. This is done by performing the integrity check of the message and by checking that 
the received UE security capabilities and the received UE nonce have not been altered compared to what the UE 
provided in the initial layer 3 message that triggered this procedure. 

If the security mode command can be accepted and the KSIasme was included in the SECURITY MODE COMMAND 
message, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS 
integrity algorithm and the NAS integrity key based on the Kasme indicated by the KSIasme- If the SECURITY MODE 
COMMAND message includes KSIsgsn- MME nonce and UE nonce, the UE shall generate K'asme from both nonces as 
indicated in 3GPP TS 33.401 [1 1] to check whether the SECURITY MODE COMMAND can be accepted or not. If the 
MME selected a NAS ciphering algorithm different from the "null ciphering algorithm", the UE shall cipher the 
SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key 
based on the Kasme indicated by the KSIasme or fresh K'asme- 

From now on the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering 
and NAS integrity algorithms. 
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If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall 
include its IMEISV in the SECURITY MODE COMPLETE message. 

9.1.3.1.3 Test description 

9.1.3.1.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.1.3.1.3.2 



Test procedure sequence 



Table 9.1.3.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


The UE transmits an ATTACH REQUEST 
message 


— > 


ATTACH REQUEST 


- 


- 


3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






5 


The SS transmits a SECURITY MODE 
COMMAND message to activate MAS security. 
It is integrity protected and includes request to 
include IMEISV 


<— 


SECURITY MODE COMMAND 






6 


Check: Does the UE transmit a SECURITY 
MODE COMPLETE message and does it 
establish the initial security configuration? 


— > 


SECURITY MODE COMPLETE 


1 


P 


7 


The SS transmits an ATTACH ACCEPT 
message. 


<— 


ATTACH ACCEPT 


- 


- 


8 


The UE transmits an ATTACH COMPLETE 
message 


— > 


ATTACH COMPLETE 


- 




9 


The SS Transmits an IDENTITY REQUEST 
message [Security protected] 


<- 


IDENTITY REQUEST 


- 


- 


10 


Check: Does the UE transmit an IDENTIY 
RESPONSE message [Security Protected]? 


-> 


IDENTITY RESPONSE 


1 


P 


11 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure for new key 
set generation. 


<— 


AUTHENTICATION REQUEST 






12 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






13 


SS resets UL and DL NAS Count to zero 


- 


- 


- 


- 


14 


The SS transmits a SECURITY MODE 
COMMAND message to activate NAS security. 
It is integrity protected and includes request to 
include IMEISV 


<— 


SECURITY MODE COMMAND 






15 


The UE transmits a NAS SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 


2 


P 




Exception : Steps 16 and 17 are executed 100 
times to check UE is applying security correctly 










16 


The SS transmits an IDENTITY REQUEST 
message [Security protected] 


<- 


IDENTITY REQUEST 


- 


- 


17 


Check: Does the UE transmit an IDENTIY 
RESPONSE message [Security Protected]? 


-> 


IDENTITY RESPONSE 


2 


P 



Editor's note: The "establishment of initial security configuration" is not described by any action neither in the TP, 
nor in the conformance requirements. If these statements are purely explanatory, they should be indicated 
as notes or removed. 

Editor's note: Does "[Security protected]" mean that it is FFS if the message is security protected, or shall it be 
security protected? 

9.1 .3.1 .3.3 Specific message contents 

Table 9.1.3.1.3.3-1: SECURITY MODE COMMAND (Steps 5 and 14) 



Derivation path: 36.508 table 4.7.2-1 9 | 


Information Element 


Value/Remarl< 


Comment 


Condition 


IMEISV request 


Present 
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Table 9.1.3.1.3.3-2: SECURITY MODE COMPLETE (Steps 6 and 15) 



Derivation path: 36.508 table 4.7.2-20 | 


Information Element 


Value/Remark 


Comment 


Condition 


IIVIEISV 


Present 







9.1.3.2 

9.1.3.2.1 
(1) 



NAS security mode command not accepted by the UE 
Test Purpose (IP) 



with { succesful completion of EPS authentication and key agreement (AKA) procedure [ } 
ensure that { 

when { UE receives an integrity protected SECURITY MODE COMMAND message including not mathcing 
replayed security capabilities} 

then { UE sends SECURITY MODE REJECT and does not start applying the NAS security in both UL and 

dl} 



9.1.3.2.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 5.4.3.1, 
5.4.3.2, 5.4.3.3 and 5.4.3.5. 

Editor's note: clauses 5.4.3.1 and 5.4.3.2 do not contain any UE requirement. 

[TS 24.301, clause 5.4.3.1] 

The purpose of the NAS security mode command (SMC) procedure is to take the new key set into use, initialise and 
start NAS signalling security between the UE and the MME, which performs integrity and replay protection as well as 
enciphering and deciphering of NAS signalling messages. 

Editor's note: It is PES whether the SMC procedure can be combined or concatenated with the attach and tracking 
area update procedures for optimisation purposes. 

[TS 24.301, clause 5.4.3.2] 

The MME initiates the NAS security mode setup command procedure by sending a SECURITY MODE COMMAND 
message to the UE and starting timer T3460. 

The MME shall integrity protect the SECURITY MODE COMMAND message with the NAS integrity key based on 
Kasme indicated by the KSIasme indicated in the message. 



The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to 
NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security 
capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed NONCEUE if the UE 
included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set 
Identifier (KSIasme or KSIsgsn)- 

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message. 

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it 
is also be supported for AS. 

[TS 24.301, clause 5.4.3.3] 

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode 
command can be accepted or not. This is done by performing the integrity check of the message and by checking that 
the received UE security capabilities and the received UE nonce have not been altered compared to what the UE 
provided in the initial layer 3 message that triggered this procedure. 

[TS 24.301, clause 5.4.3.5] 
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If the security mode command cannot be accepted, the UE shall send a SECURITY MODE REJECT message, which 
shall not be integrity protected. The SECURITY MODE REJECT message shall contain a cause code that typically 
indicates one of the following causes: 

#23: UE security capabilities mismatch; 

#24: security mode rejected, unspecified. 

Editor's note: The actions to be taken by the network are FFS. 

Upon receipt of the SECURITY MODE REJECT message, the MME shall stop timer T3460. The MME shall also abort 
the ongoing procedure that triggered the initiation of the NAS security mode setup command procedure. 



9.1.3.2.3 Test description 

9.1.3.2.3.1 Pre-test conditions 

System Simulator: 
- Cell 1 

Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.1.3.2.3.2 



Test procedure sequence 



Table 9.1.3.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


The UE transmits an ATTACH REQUEST 
message 


— > 


ATTACH REQUEST 


- 


- 


3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






5 


The SS transmits a NAS SECURITY MODE 
COIVIMAND message to activate NAS security. 
It is integrity protected and includes un 
matched replayed security capabilities. 


<— 


SECURITY MODE COMMAND 






6 


Check: Does the UE transmit a NAS 
SECURITY MODE REJECT message with 
cause'#23: UE security capabilities mismatch'? 


— > 


SECURITY MODE REJECT 


1 


P 


7 


The SS Transmits an IDENTITY REQUEST 
message for IMSI [Security not applied] 


<- 


IDENTITY REQUEST 


- 


- 


8 


The UE Transmits an IDENTIY RESPONSE 
message [Security not applied] 


-> 


IDENTITY RESPONSE 


1 


P 


9 


The SS transmits a SECURITY MODE 
COMMAND message to activate NAS security. 
It is integrity protected and includes request to 
include IMEISV 


<— 


SECURITY MODE COMMAND 






10 


The UE transmits a SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 






11 


The SS transmits an ATTACH ACCEPT 
message 


<— 


ATTACH ACCEPT 


- 


- 


12 


The UE transmits an ATTACH COMPLETE 
message 


— > 


ATTACH COMPLETE 


- 


- 



Editor's note: Does "[Security not applied]" mean that it is FFS if the message is security protected, or shall it be 
security protected? 



9.1.3.2.3.3 



Specific message contents 
Table 9.1 .3.1 .3.3-1 : SECURITY MODE COMMAND (Step 5) 



Derivation path: 36.508 table 4.7.2-1 9 | 


Information Element 


Value/Remark 


Comment 


Condition 


Replayed UE security capabilities 


Set to mismatch the 
security capability of UE 
under test 







Table 9.1.3.1.3.3-2: SECURITY MODE REJECT (Step 6 ) 



Derivation path: 36.508 table 4.7.2-21 | 


Information Element 


Value/Remark 


Comment 


Condition 


EMM cause 


#23 
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9.1.4 Identification procedure 

9.1.4.1 Identification procedure, IMSI requested 

9.1.4.1.1 Test Purpose (TP) 
(1) 

with { UE in EMM-REGISTERED state / EMM-CONNECTED mode} 
ensure that { 

when { UE receives an IDENTITY REQUEST message with IMSI in the IE Identity type } 
then { UE sends an IDENTITY RESPONSE message providing its IMSI } 
} 

9.1 .4.1 .2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clause 5.4.4.3. 

[TS 24.301, clause 5.4.4.3] 

A UE shall be ready to respond to an IDENTITY REQUEST message at any time whilst in EMM-CONNECTED 
mode. 

Upon receipt of the IDENTITY REQUEST message the UE shall send an IDENTITY RESPONSE message to the 
network. The IDENTITY RESPONSE message shall contain the identification parameters as requested by the network. 



9.1.4.1.3 


Test description 


9.1.4.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

- UE in EMM-REGISTERED state (State 2) according to [ 1 8] / EMM-CONNECTED mode 
Editor's note: No such state is defined, state 2 is "Registered, Idle mode". 



9.1.4.1.3.2 



Test procedure sequence 

Table 9.1.4.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


SS transmits an IDENTITY REQUEST 
message requesting IMSI in the IE Identity 
type 


<— 


IDENTITY REQUEST 






2 


Check: Does the UE respond with a correct 
IDENTITY RESPONSE message within 6 
seconds? 


— > 


IDENTITY RESPONSE 


1 


P 



Editor's note: there is not requirement for a UE to respond within 6 seconds. 
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9.1 .4.1 .3.3 Specific message contents 

Table 9.1.4.1.3.3-1: Message IDENTITY REQUEST (step 1, Table 9.1.4.1.3.2-1) 



Derivation path: FFS 


Information Element 


Value/Remark 


Comment 


Condition 


Identity Type 


0001 


IMS! 





Table 9.1.4.1.3.3-2: IDENTITY RESPONSE (step 2, Table 9.1.4.1.3.2-1) 



Derivation path: FFS 


Information Element 


Value/Remark 


Comment 


Condition 


iVIobile Identity 








Type of identity 


001 


IMSI 




Identity digits 


UE's IMSI 







9.2 EMM specific procedures 
9.2.1 Attach procedure 



9.2.1.1 



Attach procedure for EPS services 



9.2.1.1.1 



Attach Procedure / Success (valid GUTI) 



9.2.1.1.1.1 



Test Purpose (TP) 



(1) 

with { UE is switched-off } 
ensure that { 

when { UE is powered on and a valid GUTI is available } 

then { the UE transmits an ATTACH REQUEST message with the EPS attach type set to "initial EPS 
attach" , including GUTI and last visited registered TAI and a PDN CONNECTIVITY REQUEST message with 
the request type set to "initial attach" and not including APN } 
} 

(2) 

with { UE has sent an ATTACH REQUEST message } 
ensure that { 

when { UE receives an ATTACH_ACCEPT message with EPS attach result matching the requested 
service (s), the TAI list the UE is registered to and including an ACTIVATE DEFAULT EPS CONTEXT 
BEARER message with IE EPS Bearer Identity for the default EPS bearer context activated for the UE } 

then { UE deletes the old TAI list and transmits an ATTACH COMPLETE message, together with 
ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message and enters EMM-REGISTERED state } 



9.2.1.1.1.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 24.301, clauses 5.5.1.2.1, 
5.5.1.2.2 and 5.5.1.2.4. 

[TS 24.301, clause 5.5.1.1] 

The attach procedure is used to attach for packet services in EPS. With a successful attach procedure, a context is 
established for the UE in the MME, and a default bearer is established between the UE and the PDN GVv', thus enabling 
always-on IP connectivity to the UE. The network may also initiate the activation of dedicated bearers as part of the 
attach procedure. 



[TS 24.301, clause 5.5.1.2.1] 
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This procedure is used to attach for EPS services only. If the UE wants to keep the connection(s) to the PDN GW to 
which it has connected via non-3GPP access, the UE shall indicate "handover EPS attach" in the EPS attach type IE. 
Otherwise, the UE shall indicate "initial EPS attach".... 

[TS 24.301, clause 5.5.1.2.2] 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see figure 5.5.1.2.2.1). 



The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered TAI, if 
available. If there is no vahd GUTI available, the UE shall include the IMSI in the ATTACH REQUEST message. 

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN (see subclause 6.5.1). 



[TS 24.301, clause 5.5.1.2.4] 



If the ATTACH ACCEPT message contains a GUTI, the UE shall use this GUTI as the new temporary identity and set 
its TIN to "GUTI". The UE shall delete its old GUTI and store the new assigned GUTI. If no GUTI has been included 
by the MME in the ATTACH ACCEPT message, the old GUTI, if any available, shall be kept. 



The UE, when receiving the ATTACH ACCEPT message combined with the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST message, shall send an ATTACH COMPLETE message combined with an ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT message to the network. 



TS 24.301, clause 6.2.2] 

The UE shall set the PDN type IE in the PDN CONNECTIVITY REQUEST message based on its IP stack 
configuration as follows: 

- A UE, which is IPv6 and IPv4 capable, shall set the PDN type IE to IPv4v6. 

- A UE, which is only IPv4 capable, shall set the PDN type IE to IPv4. 

A UE, which is only IPv6 capable, shall set the PDN type IE to IPv6. 

When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are 
separated and the capability of the TE is not known in the MT), the UE shall set the PDN type IE to IPv4v6. 



[TS 24.301, clause 6.4.1.3] 

Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE shall first check 
the received uplink TFT before taking it into use. The UE shall send an ACTIVATE DEFAULT EPS BEARER 
CONTEXT ACCEPT message and enter the state BEARER CONTEXT ACTIVE. When the default bearer is activated 
as part of the attach procedure, the UE shall send the ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT 
message together with ATTACH COMPLETE message. 



The UE checks the PTI in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to identify the 
UE requested PDN connectivity procedure to which the default bearer context activation is related (see subclause 6.5.1). 

If the uplink TFT is included in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE 
shall use the received uplink TFT to apply mapping of uplink service data flows (SDFs) to the radio bearer. 
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[TS 24.301, clause 6.5.1.2] 

In order to request connectivity to the default PDN in the attach procedure, the UE shall not include any APN in the 
PDN CONNECTIVITY REQUEST message. 



The UE shall set the request type to "initial attach" when the UE is establishing connectivity to a PDN for the first time, 
i.e. when it is an initial attach to that PDN. The UE shall set the request type to "handover" when the connectivity to a 
PDN is established upon handover from a non-3GPP access network and the UE was connected to that PDN before the 
handover to the 3GPP access network. 

[TS 24.301, clause 8.3.20.2] 

This IE is included in the message when the UE wishes to request network connectivity as defined by a certain access 
point name. This IE shall not be included when the PDN CONNECTIVITY REQUEST message is included in an 
ATTACH REQUEST message. 

9.2.1.1.1.3 Test description 

9.2.1.1.1.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

- Cell 1 is a cell with TAll (PLMNl + TACl). 

The cell power levels are such that Cell 1 is guaranteed to become the serving cell 

UE: 

- The test USIM contains a valid GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 

Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.2.1.1.1.3.2 



Test procedure sequence 



Table 9.2.1.1.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


Checl<: does the UE transmit an ATTACH 
REQUEST message including a GUTI and a 
PDN CONNECTIVITY REQUEST message? 


— > 


ATTACH REQUEST 


1 


P 


3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


--> 


AUTHENTICATION RESPONSE 






5 


The SS transmits a NAS SECURITY MODE 
CQIVIMAND message to activate NAS security. 


<— 


SECURITY MODE COMMAND 


- 


- 


6 


The UE transmits a NAS SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 






7 


SS responds with ATTACH ACCEPT message 
including a valid TAI list. The ACTIVATE 
DEFAULT EPS BEARER CONTEXT 
REQUEST message is piggybacked in 
ATTACH ACCEPT message 

Note: The IP addresses of the UE are not 
allocated in this test so PDN address is not 
included in the message.. 


<— 


ATTACH ACCEPT 






8 


Check: does the UE transmit an ATTACH 
COMPLETE message including an ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT 
message? 


— > 


ATTACH COMPLETE 


1 


P 


9 


The SS releases the RRC connection. 


- 


- 


- 


- 


10 


Check: Does the test result of CALL generic 
procedure [18] indicate that the UE is in E- 
UTRA EMM-REGISTERED state on Cell 1? 






2 





Note: It is assumed in the test procedure sequence that the UE initially has a valid GUTI, hence it is included in 
ATTACH REQUEST message in step 2. However, it is not important for the test procedure sequence. 
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9.2.1.1.3.3 



Specific message contents 



Table 9.2.1 .1 .1 .3.3-1 : Message ATTACH REQUEST (step 2, Table 9.2.1 .1 .1 .3.2-1) 



Derivation path: TS 24.301 clause 8.2.4 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUT! or IMSI 


GUTI1 


Old and valid 
GUTI is included 
bytheUE 




MS network capability 


Not checked. 


Set according the 
network capability 
of UE under test 
(see TS 24.008 
clause 10.5.5.12) 




NAS key set identifier 


111 


"No key is 
available" 




Last visited registered TAI 


TAI1 


If available, the 
last TAI is 
included by UE 
and will be used 
to establish a 
good list of TAIs 
in subsequent 
ATTACH 
ACCEPT 
message. 




DRX parameter 


Not checked. 






Old LAI 


Not checked 






TMSI status 


Not checked 






ESM message container 


PDN CONNECTIVITY 
REQUEST message as 
specified in table 
9.2.1.1.1.3.2-1. 
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Table 9.2.1.1.1.3.3-2: Message PDN CONNECTIVITY REQUEST (step 2, Table 9.2.1.1.1.3.2-1) 



Derivation path: TS 24.301 clause 8.3.18 


Information Element 


Value/Remark 


Comment 


Condition 


Protocol discriminator 


ESM 






EPS bearer identity 


0000 


is used when 
the value is not 
yet assigned by 
the network. 




Procedure transaction identifier 


FFS 


Under CT1 
discussion 




Request type 


001 


Initial attach 




PDN type 


Not checked. 


The UE may 
request a PDN for 
IPv4 only or IPv6 
only even if it 
supports dual 
stack. 




Access point name 


Not present 


The UE shall not 
include any APN 
for the first time. 




Ciphered PCO transfer flag 


Not checked 






Protocol configuration options 


Not checked 


Check mandatory 
presence if PCO 
IE is present. 
(FFS) 

This IE is optional. 
This IE is 
mandatory 
present if UE has 
set the Ciphered 
PCO transfer flag. 





Table 9.2.1.1.1.3.3-3: Message ATTACH ACCEPT (step 7, Table 9.2.1.1.5.3.2-1) 



Derivation path: TS 24.301 clause 8.2.1 


Information Element 


Value/Remark 


Comment 


Condition 


EPS attach result 


001 


EPS only 




Spare half octet 


0000 






T3412value 


Default value 






TAI list 




List of 3 TAIs 




Length of tracking area identity list contents 


12 






Number of elements 


3 






Type of list 


000 


One PLMN with 
non-consecutive 
TACs 




Partial tracking area identity list 


PLMN = PLMN1 
TAC 1 = TAC1 
TAC 2 = TAC2 
TAC 3 = TAC4 






ESIVI container 


Contains the ACTIVATE 
DEFAULT EPS BEARER 
CONTEXT REQUEST 
message specified in 
table 9.2.1.1.5.3.2-1. 
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Table 9.2.1.1.1.3.3-4: Message ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (step 7, Table 

9.2.1.1.5.3.2-1) 



Derivation path: TS 24.301 clause 8.3.6 


Information Element 


Value/Remark 


Comment 


Condition 


EPS bearer identity 


Default EBId 


SS assigns a 
Default EPS 
bearer ID 
between 5 and 
15. 




Procedure transaction identifier 


FFS 


Same value as in 
in PDN 

CQNNECTIVITY 
REQUEST 




SDF QoS 


Default QoS 


SS defines a 
Default SDF QoS 




PDN address 


Not present 


The IP addresses 
of the UE are not 
allocated, so no 
new IPv4 and/or 
IPv6 addresses 
are assigned to 
theUE 




Access point name 


Arbitrary name 


SS defines a 
Default APN 




Uplink TFT 


Present. 

See default UL TFT 

defined in TS 36.508 






Negotiated QoS 


Not present 


If the UE supports 
A/Gb mode or lu 
mode or both, the 
network may 
include the 
corresponding pre 
Rel-8 QoS 
parameter values 
of a PDP context. 




Negotiated LLC SAPI 


Not present 


If the UE supports 
A/Gb mode, the 
network may 
include this IE 




Radio priority 


Not present 


If the UE supports 
A/Gb mode, the 
network may 
Include this IE. 




Packet flow Identifier 


Not present 


If the UE supports 
A/Gb mode, the 
network may 
include this IE. If 
the UE indicated 
in the UE Network 
Capability it does 
not support BSS 
packet flow 
procedures, then 
the MME shall not 
include this IE. 




Protocol configuration options 


Not present 






ESM cause 


Not present 
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Table 9.2.1.1.1.3.3-5: Message ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT (step 8, Table 

9.2.1.1.5.3.2-1) 



Derivation path: TS 24.301 clause 8.3.4 


Information Element 


Value/Remark 


Comment 


Condition 


Protocol discriminator 


ESM 






EPS bearer identity 


Default EBId 


Same value as in 

ACTIVATE 

DEFAULT EPS 

BEARER 

CONTEXT 

REOUEST 




Procedure transaction identifier 


FFS 


Same value as in 
PDN 

CONNECTIVITY 
REQUEST 




Activate default EPS bearer context accept message 
identity 


Activate default EPS 
bearer context accept 







9.2.1.1.2 



Attach Procedure / Success / With IMSI, GUTI reallocation 



9.2.1.1.2.1 



Test Purpose (TP) 



(1) 

with { UE in EMM-DEREGISTERED state } 
ensure that { 

when { there is no valid GUTI available in UE } 
then { UE sends ATTACH REQUEST message, containing IMSI as the EPS mobile identity } 
} 

(2) 

with { UE having received reallocated GUTI in the ATTACH ACCEPT message } 
ensure that { 

when { UE detaches from the EPS services } 
then { UE sends DETACH REQUEST message, containing GUTI as the EPS mobile identity } 
} 

9.2.1 .1 .2.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 24.301, clause 5.5.1.2. 

[TS 24.301, clause 5.5.1.2.2] 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see figure 5.5.1.2.2.1). If timer 
T3402 is currently running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer 
T3411. The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered 
TAI, if available. If there is no vaUd GUTI available, the UE shall include the IMSI in the ATTACH REQUEST 
message. 

[TS 24.301, clause 5.5.1.2.4] 

If the attach request is accepted by the network, the MME shall send an ATTACH ACCEPT message to the UE and 
start timer T3450. The MME shall send the ATTACH ACCEPT message together with the ACTIVATE DEFAULT 
EPS BEARER CONTEXT REQUEST message to activate the default bearer (see subclause 6.4.1). The network may 
also initiate the activation of dedicated bearers towards the UE by invoking the dedicated EPS bearer context activation 
procedure (see subclause 6.4.2). 

The MME shall assign and include the TAI list the UE is registered to in the ATTACH ACCEPT message. The UE, 
receiving an ATTACH ACCEPT message, shall delete its old TAI list and store the received TAI list. 

Upon receiving the ATTACH ACCEPT message, the UE shall stop timer T3410, reset the attach attempt counter and 
tracking area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EUl 
UPDATED. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 438 ETSI TS 136 523-1 V8.0.1 (2009-01) 

The GUTI reallocation may be part of the attach procedure. When the ATTACH REQUEST message includes the 
IMSI, the MME considers the GUTI provided by the UE is invalid, or the GUTI provided by the UE was assigned by 
another MME, the MME shall allocate a new GUTI to the UE. The MME shall include in the ATTACH ACCEPT 
message the new assigned GUTI together with the assigned TAI list. In this case the MME shall enter state EMM- 
COMMON-PROCEDURE-INITIATED as described in subclause 5.4.1. 

For a shared network, the TAIs included in the TAI list can contain different PLMN identities. 

If the ATTACH ACCEPT message contains a GUTI, the UE shall use this GUTI as the new temporary identity and set 
its TIN to "GUTI". The UE shall delete its old GUTI and store the new assigned GUTI. If no GUTI has been included 
by the MME in the ATTACH ACCEPT message, the old GUTI, if any available, shall be kept. 

Test description 

Pre-test conditions 



9.2.1, 


.1.2.3 




9.2.1 


.1.2.3.1 




System Simu 


lator 


- 


Celll 




UE: 






None. 







Preamble: 

The UE is in state Registered, Idle Mode (State 2) according to [18]. 
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9.2.1.1.2.3.2 



Test procedure sequence 



Table 9.2.1.1.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits Paging on cell 1 with IMSI. 
Upon reception of paging with IIVISI the UE 
shall locally deactivate any EPS bearer 
context{s), locally detach from EPS and delete 
the GUTI-1 . After local detach the UE shall 
perform an EPS attach procedure. 










2 


Checl<: Does the UE transmit an ATTACH 
REQUEST message including IMSI in the EPS 
mobile identity IE? 


— > 


ATTACH REQUEST 


1 


P 


3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






5 


The SS transmits a NAS SECURITY MODE 
COMMAND message to activate NAS security. 


<— 


SECURITY MODE COMMAND 


- 


- 


6 


The UE transmits a NAS SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 






7 


SS responds with ATTACH ACCEPT message 
with a new GUTI-2 included in the EPS mobile 
identity IE 


<— 


ATTACH ACCEPT 






8 


The UE transmits an ATTACH COMPLETE 
message 


— > 


ATTACH COMPLETE 


- 


- 


9 


Cause UE to detach from the EPS services 


- 


- 


- 


- 


10 


Checl<: Does the UE transmit a DETACH 
REQUEST message including GUTI-2 in the 
EPS mobile identity IE? 


--> 


DETACH REQUEST 


2 


P 


11 


SS responds with DETACH ACCEPT message 


<— 


DETACH ACCEPT 


- 


- 



9.2.1.1.2.3.3 
FFS 



Specific message contents 



9.2.1 .1 .5 Attach procedure / Success / ATTACH ACCEPT message includes the PDN 

address assigned to the UE 



9.2.1.1.5.1 



Test Purpose (TP) 



(1) 



with { UE has sent an ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH ACCEPT message with EPS attach result matching the requested 
service (s) and including an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message with IE EPS Bearer 
Identity matching the ATTACH REQUEST message and including a PDN address and an APN } 

then { UE transmits an ATTACH COMPLETE message together with ACTIVATE DEFAULT EPS BEARER CONTEXT 
ACCEPT and enters EMM-REGISTERED state } 
} 

(2) 

with { UE is in EMM-REGISTERED state and a PDN address for an active default EPS bearer was received 
in an ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message } 
ensure that { 

when { UE receives an ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message linked to the existing 
default EPS bearer } 

then { UE transmits an ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT messages } 
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9.2.1.1.5.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.5.1.1, 
5.5.1.2.1, 5.5.1.2.2, 5.5.1.2.4, 6.2.2, 6.4.1.3 and 6.5.1.2. 

[TS 24.301, clause 5.5.1.1] 

The attach procedure is used to attach for packet services in EPS. With a successful attach procedure, a context is 
established for the UE in the MME, and a default bearer is established between the UE and the PDN GW, thus enabling 
always-on IP connectivity to the UE. The network may also initiate the activation of dedicated bearers as part of the 
attach procedure. 



[TS 24.301, clause 5.5.1.2.1] 

This procedure is used by a UE to attach for EPS services only. When the UE initiates the EPS attach procedure, the UE 
shall indicate "EPS attach" in the EPS attach type IE. 

[TS 24.301, clause 5.5.1.2.2] 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see figure 5.5.1.2.2.1). 



The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered TAI, if 
available. If there is no valid GUTI available, the UE shall include the IMSI in the ATTACH REQUEST message. 

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN (see subclause 6.5.1). 

The UE may also indicate the DRX parameter. 

If a valid NAS security context exists, the UE shall integrity protect the ATTACH REQUEST message combined with 
the PDN CONNECTIVITY REQUEST message. When the UE does not have a valid NAS security context, the 
ATTACH REQUEST message combined with the PDN CONNECTIVITY REQUEST message is not integrity 
protected. 

[TS 24.301, clause 5.5.1.2.4] 



If the ATTACH ACCEPT message contains a GUTI, the UE shall use this GUTI as the new temporary identity and set 
its TIN to "GUTI". The UE shall delete its old GUTI and store the new assigned GUTI. 



The UE, when receiving the ATTACH ACCEPT message combined with the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST message, shall send an ATTACH COMPLETE message combined with an ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT message to the network. 



[TS 24.301, clause 6.2.2] 

The UE shall set the PDN type IE in the PDN CONNECTIVITY REQUEST message based on its IP stack 
configuration as follows: 

- A UE, which is IPv6 and IPv4 capable, shall set the PDN type IE to IPv4v6. 

- A UE, which is only IPv4 capable, shall set the PDN type IE to IPv4. 

A UE, which is only IPv6 capable, shall set the PDN type IE to IPv6. 

When the IP version capability of the UE is unknown in the UE (as in the case when the MT and TE are 
separated and the capability of the TE is not known in the MT), the UE shall set the PDN type IE to IPv4v6. 
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[TS 24.301, clause 6.4.1.3] 

Upon receipt of the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message, the UE shall send an 
ACTIVATE DEFAULT EPS BEARER CONTEXT ACCEPT message and enter the state BEARER CONTEXT 
ACTIVE. When the default bearer is activated as part of the attach procedure, the UE shall send the ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT message together with ATTACH COMPLETE message. 



The UE checks the PTI in the ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST message to identify the 
UE requested PDN connectivity procedure to which the default bearer context activation is related (see subclause 6.5.1). 



[TS 24.301, clause 6.4.2.3] 

Upon receipt of the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE shall first 
check the received uplink TFT before taking it into use. Then the UE shall send an ACTIVATE DEDICATED EPS 
BEARER CONTEXT ACCEPT message and enter the state BEARER CONTEXT ACTIVE. The ACTIVATE 
DEDICATED EPS BEARER CONTEXT ACCEPT message shall include the EPS bearer identity. 

The linked EPS bearer identity included in the ACTIVATE DEDICATED EPS BEARER CONTEXT 
REQUEST message indicates to the UE to which default bearer, IP address and PDN the dedicated bearer is 
linked. 

If the PTI is included in the ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST message, the UE 
uses the PTI to identify the UE requested bearer resource allocation procedure to which the dedicated bearer 
context activation is related (see subclause 6.5.3). 

The UE shall use the received uplink TFT to apply mapping of uplink service data flows (SDFs) to the radio bearer. 



[TS 24.301, clause 6.5.1.2] 

In order to request connectivity to the default PDN in the attach procedure, the UE shall not include any APN in the 
PDN CONNECTIVITY REQUEST message. 



The UE shall set the request type to "initial attach" when the UE is establishing connectivity to a PDN for the first time, 
i.e. when it is an initial attach to that PDN. The UE shall set the request type to "handover" when the connectivity to a 
PDN is established upon handover from a non-3GPP access network and the UE was connected to that PDN before the 
handover to the 3GPP access network. 



9.2.1.1.5.3 Test description 

9.2.1.1.5.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

UE: 

- The test USIM contains GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 

Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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Note: The PDN type (IPv4, IPv6 or both) of the UE is determined by the PICS . 



9.2.1.1.5.3.2 



Test procedure sequence 



Table 9.2.1.1.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


The UE transmit an ATTACH REQUEST 
message including a PDN CONNECTIVITY 
REQUEST message. 


— > 


ATTACH REQUEST 






3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






5 


The SS transmits a SECURITY MODE 
COMMAND message to activate MAS security. 


<— 


SECURITY MODE COMMAND 


- 


- 


6 


The UE transmits a SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 






7 


The SS transmits an ATTACH ACCEPT 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT REQUEST 
message. 

Note: in the DEFAULT EBC REQUEST 
message, the SS allocates a PDN address of a 
PDN type which is compliant with the PDN 
type requested by the UE. 


<— 


ATTACH ACCEPT 






8 


Check: Does the UE transmit an ATTACH 
COMPLETE message including ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT 
message as specified? 


— > 


ATTACH COMPLETE 


1 


P 


9 


The SS transmits an ACTIVATE DEDICATED 
EPS BEARER CONTEXT REQUEST. 

Note: the same PDN address is applicable 
because the linked EPS bearer ID refers to the 
default EBC allocated in step 7. 


<— 


ACTIVATE DEDICATED EPS 
BEARER CONTEXT REQUEST 






10 


Check: Does the UE transmit an ACTIVATE 
DEDICATED EPS BEARER CONTEXT 
ACCEPT message as specified? 


— > 


ACTIVATE DEDICATED EPS 
BEARER CONTEXT ACCEPT 


2 


P 


11 


The SS releases the RRC connection. 


- 


- 


- 


- 


12 


Check: Does the test results of CALL generic 
procedure indicate that the UE is in E-UTRA 
EMM-REGISTERED state with S-TMSI2? 






1 
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9.2.1.1.5.3.3 



Specific message contents 



Table 9.2.1.1.5.3.3-1 : Message ACTIVATE DEFAULT EPS BEARER CONTEXT REQUEST (step 7, Table 

9.2.1.1.5.3.2-1) 



Derivation path: 36.508 table 4.7.3-6 | 


Information Element 


Value/Remark 


Comment 


Condition 


EPS bearer identity 


Default EBId 


SS assigns a 
Default EPS 
bearer ID between 
5 and 15. 




PDN address 








PDN type 


Same value like the 
"PDN type" in the PDN 
CONNECTIVITY 
REOUEST message in 
step 2 or 01 1 is it was 
unknown 






PDN address 


IPv4 Address (octet 4 to 
7), IPv6 Address (octet 4 
to 11) or IPv6 Address 






(octet 4 to 1 1 ) and IPv4 Address (octet 1 2 to 1 5) 


SS assigns private 






according to PDN type above 


IPv6/IPv4 address(es) 







Table 9.2.1.1.5.3.3-2: Message ACTIVATE DEDICATED EPS BEARER CONTEXT REQUEST (step 9, 

Table 9.2.1.1.5.3.2-1) 



Derivation path: 36.508 table 4.7.3-3 


Information Element 


Value/Remark 


Comment 


Condition 


EPS bearer identity 


EBId-1 


SS assigns an 
EPS bearer ID 
between 5 and 1 5 
different from 
Default EBId. 




Procedure transaction identifier 


FFS 


Under CT1 
discussion 




Linked EPS bearer identity 


Default EBId (same value 
like in table 9.2.1.1.5.3.3- 






SDF QoS 


1} 

Default dedicated QoS 


SS defines a 
Default dedicated 
SDF QoS 




Uplink TFT 


Present (value is FFS) 







Table 9.2.1.1.5.3.3-3: Message ACTIVATE DEDICATED EPS BEARER CONTEXT ACCEPT (step 10, 

Table 9.2.1.1.5.3.2-1) 



Derivation path: 36.508 table 4.7.3-1 | 


Information Element 


Value/Remark 


Comment 


Condition 


EPS bearer identity 


EBId-1 


Same value as in 

ACTIVATE 

DEDICATED EPS 

BEARER 

CONTEXT 

REQUEST 




Procedure transaction identifier 


FFS 


Under CT1 
discussion 





9.2.1 .1 .9 Attach / rejected / IMSI invalid 

Editor's note: The contents of this section are aligned with 3GPP TS 24.301 vl.1.0 
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9.2.1.1.9.1 



Test Purpose (TP) 



(1) 

with { UE has sent an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH REJECT message with the reject cause set to "Illegal MS" } 

then { UE considers the USIM as invalid for EPS services and non-EPS services and enters state 
EMM-DEREGISTERED } 
} 

9.2.1.1.9.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.5.1.2.5. 

[TS 24.301, clause 5.5.1.2.5] 



Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the reject cause value received. 

#3 (Illegal MS); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTl, last visited registered TAI and KSI. The UE shall consider the 
USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is 
removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM- 
DEREGISTERED. 



9.2.1.1.9.3 
9.2.1.1.9.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1, Cell 2 and Cell 3 

TAIs are assigned according to table 9.2.1.1.9.3.1-1. 

Table 9.2.1.1.9.3.1-1: TAI for simulated cells 



UE: 



Cells 


TAI 


MNC 


MCC 


TAC 


CelM 


1 


1 


1 


Cell 2 


1 


1 


2 


Cell 3 


2 


1 


1 



The test USIM contains IMSIl, GUTll and TAIl, and EPS update status is "EUl: UPDATED". 



Preamble: 

- The UE is in state Switched OFF (state 1) according to clause [18]. 
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9.2.1.1.9.3.2 



Test procedure sequence 



Table 9.2.1.1.9.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS configures: 

- Cell 1 as the "Serving cell". 

- Cell 2 as a "Non-Suitable cell". 

- Cell 3 as a "Non-Suitable cell". 










2 


The UE is switched on. 


- 


- 


- 


- 


3 


The UE transmits an ATTACH REQUEST 
message including a PDN CONNECTIVITY 
REQUEST message on cell 1 . 


— > 


ATTACH REQUEST 






4 


The SS transmits an ATTACH REJECT 
message with EMM cause = "Illegal MS" as 
specified. 


<— 


ATTACH REJECT 






5 


The SS releases the RRC connection. 


- 


- 


- 


- 


6 


The SS configures: 

- Cell 1 as a "Non-Suitable cell". 

- Cell 2 as the "Serving cell". 










7 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds on 
cell 2 or on cell 1? 

Note: Cell 2 belongs to the same PLMN where 
the UE was rejected but a different TA 


— > 


ATTACH REQUEST 


1 


F 


8 


The operator initiates an attach by MMI or by 
AT command. 


- 


- 


- 


- 


9 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds on 
cell 2 or on cell 1? 


— > 


ATTACH REQUEST 


1 


F 


10 


Check: Does the test result of CALL generic 
procedure indicate that the UE ignores paging 
on cell 2 for PS domain with IMSI1 ? 






1 




11 


Check: Does the test result of CALL generic 
procedure indicate that the UE ignores paging 
on cell 2 for PS domain with GUTI1 ? 






1 




12 


The SS configures: 

- Cell 2 as a "Non-Suitable cell". 

- Cell 3 as the "Serving cell". 










13 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds on 
cell 3 or on cell 2? 

Note: Cell 3 belongs to a PLMN which is not 
the same like the one on which the UE was 
rejected. 


— > 


ATTACH REQUEST 


1 


F 


14 


The user initiates an attach by MMI or by AT 
command. 


- 


- 


- 


- 


15 


Check : Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds on 
cell 3 or on cell 2? 


— > 


ATTACH REQUEST 


1 


F 



9.2.1 .1 .9.3.3 Specific message contents 

Table 9.2.1.1.9.3.3-1: Message ATTACH REJECT (step 4, Table 9.2.1.1.9.3.2-1) 



Derivation path: 36.508 table 4.7.2.3 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 

EMM cause 

ESM message container 


0000 

0000001 1 
Not present 


"No security 
protection" 
#3 "Illegal MS" 
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9.2.1 .1 .10 Attach / rejected / illegal UE 

9.2.1.1.10.1 Test Purpose (TP) 
(1) 

with { UE has sent an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH REJECT message with the reject cause set to "Illegal ME" } 

then { UE considers the USIM as invalid for EPS services and non-EPS services and enters state 
EMM-DEREGISTERED } 
} 

9.2.1 .1 .1 0.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.5.1.2.5. 
[TS 24.301, clause 5.5.1.2.5] 



Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the reject cause value received. 

#6 (Illegal ME); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAl and KSI. The UE shall consider the 
USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is 
removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM- 
DEREGISTERED. 



9.2.1.1.10.3 Test description 

The test description is identical to the one of subclause 9.2.1.1.9 except that the reject cause #3 "Illegal MS" is replaced 
with the reject cause #6 "Illegal UE". 

9.2.1 .1 .1 1 Attach / rejected / GPRS services and non-GPRS services not allowed 

9.2.1.1.11.1 Test Purpose (TP) 
(1) 

with { UE has sent an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH REJECT message with the reject cause set to "Illegal ME" } 

then { UE considers the USIM as invalid for EPS services and non-EPS services and enters state 
EMM-DEREGISTERED } 
} 

9.2.1 .1 .1 1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clause 5.5.1.2.5. 
[TS 24.301, clause 5.5.1.2.5] 



Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the reject cause value received. 

#8 (GPRS services and non-GPRS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the 
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USIM as invalid for EPS services and non-EPS services until switching off or the UICC containing the USIM is 
removed. Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM- 
DEREGISTERED. 



9.2.1.1.11.3 Test description 

The test description is identical to the one of subclause 9.2.1.1.9 except that the reject cause #3 "Illegal MS" is replaced 
with the reject cause #8 "GPRS services and non-GPRS services not allowed". 

9.2.1 .1 .12 Attach / rejected / GPRS services not allowed 

9.2.1.1.12.1 Test Purpose (TP) 
(1) 

with { UE has sent an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH REJECT message with the reject cause set to "GPRS services not 
allowed" } 

then { UE deletes the GUTI and the last visited registered TAI and KSI and considers the USIM as 
invalid for EPS services until switching off or the UICC containing the USIM is removed and deletes 
the list of equivalent PLMNs and UE enters state EMM-DEREGISTERED } 
} 

9.2.1 .1 .12.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.5.1.2.2 and 
5.5.1.2.5. 

[TS 24.301, clause 5.5.1.2.2] 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see figure 5.5.1.2.2.1). If timer 
T3402 is currently running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer 
T3411. The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered 
TAI, if available. If there is no valid GUTI available, the UE shall include the IMSI in the ATTACH REQUEST 
message. 

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN (see subclause 6.5.1). 



[TS 24.301, clause 5.5.1.2.5] 

If the attach request cannot be accepted by the network, the MME shall send an ATTACH REJECT message to the UE 
including an appropriate reject cause value. 



Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the reject cause value received. 

#7 (GPRS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. The UE shall consider the 
USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
Additionally, the UE shall delete the list of equivalent PLMNs and enter state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the GMM parameters GMM 
state, GPRS update status, P-TMSI, P-TMSI signature, RAI and GPRS ciphering key sequence number as 
specified in 3GPP TS 24.008 [6] for the case when the normal attach procedure is rejected with this cause value. 
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9.2.1.1.12.3 Test description 

9.2.1.1.12.3.1 Pre-test conditions 

System Simulator: 

- Cell 1, Cell 2 and Cell 3: 

- Cell 1 in MCCl/MNCl/TACl (TAI-1), 

- Cell 2 in MCC1/MNC1/TAC2 (TAI-3), 

- Cell 3 in MCC2/MNC1/TAC1 (TAI-2). 

- If pc_GERAN or pc_UTRAN supported by UE, Cell A (GERAN or UTRAN) with MCC1/MNC2 - NM02 
The different cells may not be simultaneously activated. 

UE: 

- The test USIM contains IMSIl, GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 

- If pc_GERAN or pc_UTRAN supported by UE, the test USIM contains P-TMSI 1 , P-TMSI signature 1 and 
RAIl, and GPRS update status is "GUI: UPDATED". 

Preamble: 

The UE is in state Switched OFF (state 1) according to clause [18]. 
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9.2.1.1.12.3.2 



Test procedure sequence 



Table 9.2.1.1.12.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS configures: 

- Cell 1 as the "Serving cell". 

- Cell 2 as a "Non-Suitable cell". 

- Cell 3 as a "Non-Suitable cell". 

IF pc_GERAN or pc_UTRAN THEN the SS 
configures Cell A as "Non-Suitable cell". 










- 


The following messages are sent and shall be 
received on cell 1 . 


- 


- 


- 


- 


2 


The user switches the UE on. 


- 


- 


- 


- 


3 


The UE transmit an ATTACH REQUEST 
message including a PDN CONNECTIVITY 
REQUEST message. 


— > 


ATTACH REQUEST 






4 


The SS transmits an ATTACH REJECT 
message with EMM cause = "GPRS services 
not allowed". 


<— 


ATTACH REJECT 






5 


The SS releases the RRC connection. 


- 


- 


- 


- 


6 


The SS reconfigures: 

Cell 1 as a "Non-Suitable cell". 

Cell 2 as the "Serving cell". 

Note: Cell 1 and Cell 2 are in different TAIs - 
same PLMN. 










- 


The following messages are sent and shall be 
received on cell 2. 


- 


- 


- 


- 


7 


Checl<: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


1 


F 


8 


The user initiates an attach by MMI or by AT 
command. 


- 


- 


- 


- 


9 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


1 


F 


- 


EXCEPTION: Steps Hal to 11a6 describe 
behaviour that depends on the UE capability. 


- 


- 


- 


- 


10a 

1 


IF pc_UTRAN or pc_GERAN THEN 
the SS configures 

- Cell 2 as a "Non-Suitable cell". 

- Cell A as the "Serving cell". 

Note: Cell 2 and Cell A are in different PLMNs 










10a 
2 


The following messages are sent and shall be 
received on cell A. 


- 


- 


- 


- 


10a 
3 


IF pc_CS THEN the UE registers on CS 
domain - See TS 34.1 08 or TS 51.010 

Note: This is applied only for UE in UE 
operation mode A or in class A or in class B. 










10a 
4 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 2 minutes? 


— > 


ATTACH REQUEST 


1 


F 


10a 
5 


The user initiates an attach by MMI or by AT 
command. 


- 


- 


- 


- 


10a 
6 


Check : Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


1 


F 


11 


The SS configures: 

- Cell 2 as a "Non-Suitable cell". 

- Cell 3 as the "Serving cell". 

Note: Cell 2 and Cell 3 are different PLMNs. 










- 


The following messages are sent and shall be 
received on cell 3. 


- 


- 


- 


- 


12 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


1 


F 
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The operator initiates an attach by MMI or by 
AT command. 



13 



14 



Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 



ATTACH REQUEST 



9.2.1 .1 .12.3.3 Specific message contents 

Table 9.2.1.1.12.3.3-1: Message ATTACH REJECT (step 4, Table 9.2.1.1.12.3.2-1) 



Derivation path: 36.508 table 4.7.2.3 (This message is transmitted as a "plain NAS message") 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 
EMM cause 

ESM message container 


0000 
000001 1 1 

Not present 


"No security 
protection" 
#7 "GPRS 
services not 
allowed" 





9.2.1.1.13 Attach / rejected / PLMN not allowed 

9.2.1.1.13.1 Test Purpose (TP) 

(1) 

with { UE has sent an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH REJECT message with the reject cause set to "PLMN not allowecJ" } 
then { UE cJeletes the GUTI , the last visitecJ registerecJ TAI ancJ KSI an(3 UE (deletes the list of 
equivalent PLMNs and UE enters state EMM-DEREGISTERED. PLMN-SEARCH and UE stores the PLMN in the 
"forbidden PLMN list" } 
} 

(2) 

with { UE is switched off and a PLMN is stored in the "forbidden PLMN list" } 
ensure that { 

when { UE is powered on this PLMN } 

then { UE doesn't perform an attach procedure } 
} 

(3) 

with { UE in E-UTRA EMM-DEREGISTERED . PLMN-SEARCH state and a PLMN is stored in the "forbidden PLMN 
list" } 
ensure that { 

when { UE enters a PLMN which is not in the "forbidden PLMN list" } 
then { UE performs an attach procedure } 
} 

(4) 

with { UE in E-UTRA EMM-DEREGISTERED . PLMN-SEARCH state and a PLMN is stored in the "forbidden PLMN 
list" } 
ensure that { 

when { UE is in the rejected PLMN and when that PLMN is selected manually } 
then { UE performs an attach procedure } 



9.2.1.1.13.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.5.1.2.2 and 
5.5.1.2.5. 

[TS 24.301, clause 5.5.1.2.2] 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see figure 5.5.1.2.2.1). If timer 
T3402 is currently running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 451 ETSI TS 136 523-1 V8.0.1 (2009-01) 

T3411. The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered 
TAI, if available. If there is no valid GUTI available, the UE shall include the IMSI in the ATTACH REQUEST 

message. 

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN (see subclause 6.5.1). 



[TS 24.301, clause 5.5.1.2.5] 

If the attach request cannot be accepted by the network, the MME shall send an ATTACH REJECT message to the UE 
including an appropriate reject cause value. 



Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the reject cause value received. 

#1 1 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally, the UE shall 
delete the list of equivalent PLMNs, reset the attach attempt counter, and enter state EMM- 
DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [3]. 

If A/Gb mode or lu mode is supported by the UE, the UE shall in addition handle the MM parameters update 
status, TMSI, LAI, ciphering key sequence number and location update attempt counter, and the GMM 
parameters GMM state, GPRS update status, P-TMSI, P-TMSI signature, RAI, GPRS ciphering key sequence 
number and GPRS attach attempt counter as specified in 3GPP TS 24.008 [6] for the case when the normal 
attach procedure is rejected with this cause value and no RR connection exists. 

9.2.1.1.13.3 Test description 

9.2.1.1.13.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 , Cell 2, Cell 3, and Cell 4 

- Cell 1 in MCC1/MNC2/TAC1 (TAI-1) 

- Cell 2 in MCC1/MNC2/TAC1 (TAI-1), 

- Cell 3 in MCC 1/MNC2/TAC2 (TAI-2), 

- Cell 4 in MCC2/MNC1/TAC1 (TAI-3). 

- MCC1/MNC2 and MCC2/MNC1 are not HPLMN of the UE. 
The cells may not be simultaneously activated. 

UE: 

- The test USIM contains IMSIl, GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 

- The "forbidden PLMN list" is empty. 

Preamble: 

The UE is in state Switched OFF (state 1) according to clause [18]. 
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9.2.1.1.13.3.2 



Test procedure sequence 



Table 9.2.1.1.13.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS configures: 

- Cell 1 as the "Serving cell". 

- Cell 2 as a "Non-Suitable cell". 

- Cell 3 as a "Non-Suitable cell". 

- Cell 4 as a "Non-Suitable cell". 










2 


The following messages are sent and shall be 
received on cell 1 . 


- 


- 


- 


- 


3 


The UE is switched on. 


- 


- 


- 


- 


4 


The UE transmits an ATTACH REQUEST 
message including a PDN CONNECTIVITY 
REQUEST message. 


— > 


ATTACH REQUEST 






5 


The SS transmits an ATTACH REJECT 
message including EMM cause = "PLMN not 
allowed". 


<— 


ATTACH REJECT 






6 


The SS releases the RRC connection. 


- 


- 


- 


- 


7 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


- 


- 


1 


F 


8 


If possible (see ICS) switch off is performed. 
Qtherwise the power is removed. 


- 


- 


- 


- 


9 


The SS configures: 

- Cell 1 as a "Non-Suitable cell". 

- Cell 2 as the "Serving cell". 

Note: Cell 1 and Cell 2 are in the same TAI - 
same PLMN. 










10 


The following messages are sent and shall be 
received on cell 2. 


- 


- 


- 


- 


11 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


3 


F 


12 


The user initiates an attach by MMI or by AT 
command. 


- 


- 


- 


- 


13 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


1 


F 


14 


The SS configures: 

Cell 2 as a "Non-Suitable cell". 

Cell 3 as the "Serving cell". 

Note: Cell 2 and Cell 3 are in the different TAI 
-same PLMN. 










15 


The following messages are sent and shall be 
received on cell 3. 


- 


- 


- 


- 


16 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


2 


F 


17 


The user initiates an attach by MMI or by AT 
command. 


- 


- 


- 


- 


18 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


1 


F 


19 


The SS configures: 

Cell 3 as a "Non-Suitable cell". 

Cell 4 as the "Serving cell". 

Note: Cell 3 and Cell 4 are different PLMNs. 










20 


The following messages are sent and shall be 
received on cell 4. 


- 


- 


- 


- 


21 


Check: Does the UE transmit an ATTACH 
REQUEST message including a PDN 
CONNECTIVITY REQUEST message as 
specified? 


— > 


ATTACH REQUEST 


4 


P 


22 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 
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23 


The UE transmits an AUTHENTICATION 
RESPONSE message. 


— > 


AUTHENTICATION REQUEST 


- 


- 


24 


The SS starts integrity protection and ciphering 


<— 


SECURITY MODE COMMAND 


- 


- 


25 


The UE responds to the SS. 


— > 


SECURITY MODE COMPLETE 


- 


- 


26 


The SS transmits an ATTACH ACCEPT 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT REOUEST 
message. 


<— 


ATTACH ACCEPT 






27 


The UE transmits an ATTACH COMPLETE 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 






28 


The SS releases the RRC connection. 


- 


- 


- 


- 


29 


The user switches the UE off. 


- 


- 


- 


- 


30 


The UE transmits a DETACH REOUEST 
message. 


— > 


DETACH REQUEST 


- 


- 


31 


The SS configures: 

Cell 1 as the "Serving cell". 

Cell 4 as a "Non-suitable cell". 

Note: Cell 1 belong to the forbidden PLMN. 










32 


The user switches the UE on. 


- 


- 


- 


- 


33 


The following messages are sent and shall be 
received on cell 1 . 


- 


- 


- 


- 


34 


The user sets the UE in manual PLIVIN 
selection mode or requests a PLMN search. 


- 


- 


- 


- 


35 


The user selects PLMN {MCC=1 , MNC=2) 


- 


- 


- 


- 


36 


Check: Does the UE transmit an ATTACH 
REOUEST message including a PDN 
CONNECTIVITY REOUEST message as 
specified? 


--> 


ATTACH REOUEST 


5 


P 


37 


The SS transmits an AUTHENTICATION 
REOUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






38 


The UE transmits an AUTHENTICATION 
RESPONSE message. 


— > 


AUTHENTICATION REQUEST 


- 


- 


39 


The SS starts integrity protection and ciphering 


<— 


SECURITY MODE COMMAND 


- 


- 


40 


The UE responds to the SS. 


— > 


SECURITY MODE COMPLETE 


- 


- 


41 


The SS transmits an ATTACH ACCEPT 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT REOUEST 
message. 


<— 


ATTACH ACCEPT 






42 


The UE transmits an ATTACH COMPLETE 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 







9.2.1.1.13.3.3 Specific message contents 

Table 9.2.1.1.13.3.3-1: Message ATTACH REJECT (step 5, Table 9.2.1.1.13.3.2-1) 



Derivation path: 36.508 table 4.7.2.3 (Plain 


NAS message) 






Information Element 


Value/Remark 


Comment 


Condition 


Security header type 




0000 


"No security 
protection" 




EMM cause 




00001011 


#11 "PLMN not 
allowed" 




ESM message container 




Not present 
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Table 9.2.1.1.13.3.3-2: Message ATTACH REQUEST (step 21, Table 9.2.1.1.13.3.2-1) 



Derivation path: 36.508 table 4.7.2.4 | 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUTI or IMSI 


IMSI1 


GUTI has been 
deleted after 
receiving 

ATTACH REJECT 
at step 5; only 
IMSI is available. 




Last visited registered TAI 


Not present 


TAI has been 
deleted after 
receiving 

ATTACH REJECT 
at step 5. 





9.2.1.1.14 Attach / rejected / tracking area not allowed 

Editor's note; The contents of this section are aligned with 3GPP TS 24.301 v 1.1.1. 



9.2.1.1.14.1 
(1) 



Test Purpose (TP) 



with { UE has sent an ATTACH REQUEST message including a PDN CONNECTIVITY REQUEST message } 
ensure that { 

when { UE receives an ATTACH REJECT message with the reject cause set to "Tracking area not 
allowed" } 

then { UE sets the EPS update status to EU3 ROAMING NOT ALLOWED, UE deletes the GUTI, last 
visited registered TAI and KSI, UE enters the state EMM-DEREGISTERED .LIMITED-SERVICE and UE stores 
the current TAI in the list of "forbidden tracking areas for regional provision of service" } 
} 

(2) 

with { UE is in EMM-DEREGISTERED. LIMITED-SERVICE state and the current TAI in the list of "forbidden 
tracking areas for regional provision of service"} 
ensure that { 

when { serving cell belongs to TAI where UE was rejected } 
then { UE does not attempt to attach on any other cell } 
} 

(3) 

with { UE is in EMM-DEREGISTERED .LIMITED-SERVICE state and the current TAI in the list of "forbidden 
tracking areas for regional provision of service"} 
ensure that { 

when { UE re- selects a new cell in the same TAI it was rejected } 
then { UE does not attempt to attach } 
} 

(4) 

with { UE is in EMM-DEREGISTERED. LIMITED-SERVICE state and the current TAI in the list of "forbidden 
tracking areas for regional provision of service"} 
ensure that { 

when { UE enters a cell belonging to a tracking area not in the list of "forbidden tracking areas 
for regional provision of service"} 

then { UE attempts to attach with IMSI } 
} 

(5) 

with { UE is in EMM-DEREGISTERED. LIMITED-SERVICE state and the list of "forbidden tracking areas for 
regional provision of service" contains more than one TAI } 
ensure that { 

when { UE re-selects a cell belonging to one of the TAIs in the list of "forbidden tracking areas 
for regional provision of service" } 

then { UE does not attempt to attach } 
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(6) 

with { UE is switched off } 
ensure that { 

when { UE is powered on in the cell belonging to the TAI which was in the list of "forbidden 
tracking areas for regional provision of service" before the UE was swithed off } 
then { UE performs registration on that cell } 
} 

9.2.1.1.14.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.3.2, 
5.5.1.2.2, 5.5.1.2.5, 5.2.2.3.2, and Annex C. 

[TS 24.301, clause 5.3.2] 

The UE shall store a list of "forbidden tracking areas for roaming", as well as a list of "forbidden tracking areas for 
regional provision of service". These lists shall be erased when the UE is switched off or when the USIM is removed, 
and periodically (with a period in the range 12 to 24 hours). 



Each list shall accommodate 10 or more TAIs. When the list is full and a new entry has to be inserted, the oldest entry 
shall be deleted. 



[TS 24.301, clause 5.5.1.2.2] 

In state EMM-DEREGISTERED, the UE initiates the attach procedure by sending an ATTACH REQUEST message to 
the MME, starting timer T3410 and entering state EMM-REGISTERED-INITIATED (see figure 5.5.1.2.2.1). 



The UE shall include in the ATTACH REQUEST message a valid GUTI together with the last visited registered TAI, if 
available. If there is no valid GUTI available, the UE shall include the IMSl in the ATTACH REQUEST message. 

The UE shall send the ATTACH REQUEST message together with a PDN CONNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN (see subclause 6.5.1). 



[TS 24.301, clause 5.5.1.2.5] 



Upon receiving the ATTACH REJECT message, the UE shall stop timer T3410 and take the following actions 
depending on the reject cause value received. 



#12 (Tracking area not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI and KSI. Additionally, the UE shall 
reset the attach attempt counter and enter the state EMM-DEREGISTERED.LIMITED-SERVICE. 

The UE shall store the current TAJ in the list of "forbidden tracking areas for regional provision of service". 



[TS 24.301, clause 5.2.2.3.2] 

The UE shall perform an attach procedure when entering a cell which provides normal service. 

[TS 24.301, Annex C (normative)] 

The following EMM parameters shall be stored on the USIM if the corresponding file is present: 
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- GUTI; 

last visited registered TAI; 

- EPS update status; 

- Allowed CSG list. 

NOTE: The corresponding files on the USIM will not be available if the USIM inserted in the UE is a pre-Rel-8 
USIM. 

Editor's note: Whether security context parameters need to be stored on the USIM to handle the case the USIM 
application on the UICC is changed is FFS. 

If the corresponding file is not present on the USIM, these EMM parameters are stored in a non-volatile memory in the 
ME together with the IMSI from the USIM. These EMM parameters can only be used if the IMSI from the USIM 
matches the IMSI stored in the non-volatile memory; else the UE shall delete the EMM parameters. 

9.2.1.1.14.3 Test description 

9.2.1 .1 .14.3.1 Pre-test conditions 

System Simulator: 

- Cell 1, Cell 4, Cell 2 and Cell 3: 

- Cell 1 and Cell 4 in MCCl/MNCl/TACl (TAI-1), 

- Cell 2 in MCC1/MNC1/TAC2 (TAI-3), 

- Cell 3 in MCC2/MNC1/TAC1 (TAI-2). 

Note 1: Cell 3 is present to confirm that UE shall not perform PLMN search after reject from the SS. 

Note 2: Cell 4 is present to confirm that UE shall not attempt attach to the cell in same TAI after reject from the 
SS. 

UE: 
None. 

Preamble: 

The UE is in state Switched OFF (state 1) according to clause [18]. 

- The test USIM contains IMSIl, GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 
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9.2.1.1.14.3.2 



Test procedure sequence 



Table 9.2.1.1.14.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS configures: 
Cell 1 as the "Serving cell". 
Cell 4 as a "Non-Suitable cell", 
Cell 2 as a " Suitable cell", 
Cell 3 as a " Suitable cell". 










2 


The UE is switched on. 


- 


- 


- 


- 


3 


The UE transmits an ATTACH REQUEST 
message including a PDN CONNECTIVITY 
REQUEST message as specified on Cell 1 . 


— > 


ATTACH REQUEST 






4 


The SS transmits an ATTACH REJECT 

message, EMM cause = "Tracking area not 

allowed". 

(The list of "forbidden tracking areas for 

roaming" in the UE should now contain TAI-1) 


<— 


ATTACH REJECT 






5 


The SS releases the RRC connection. 


- 


- 


- 


- 


6 


Check: Does the UE transmit the ATTACH 
REQUEST message in the next 30 seconds on 
Cell 2 and Cell 3? 


— > 


ATTACH REQUEST 


2 


F 


7 


The user initiates an attach by MMI or by AT 
command. 


- 


- 


- 


- 


8 


Check: Does the UE transmit the ATTACH 
REQUEST message in the next 30 seconds on 
Cell 1? 


— > 


ATTACH REQUEST 


1 


F 


9 


The SS reconfigures: 
Cell 1 as a "Non-Suitable cell". 
Cell 4 as the "Serving cell". 
Cell 2 as a " Suitable cell". 
Cell 3 as a " Suitable cell". 










10 


Check: Does the UE transmit the ATTACH 
REQUEST message in the next 30 seconds on 
any cell? 


— > 


ATTACH REQUEST 


3 


F 


11 


The SS reconfigures: 
Cell 1 as a " Non-Suitable cell". 
Cell 4 as a "Suitable cell". 
Cell 2 as the "Serving cell". 
Cell 3 as a " Suitable cell". 










12 


The following messages are sent and shall be 
received on Cell 2. 


- 


- 


- 


- 


13 


Check: Does the UE transmit the ATTACH 
REQUEST message including a PDN 
CONNECTIVITY REQUEST message as 
specified? 


— > 


ATTACH REQUEST 


4 


P 


14 


The SS transmits an ATTACH REJECT 

message, EMM cause = "Tracking area not 

allowed". 

(The list of "forbidden tracking areas for 

roaming" in the UE should now contain TAI-1 

and TAI-3) 


<— 


ATTACH REJECT 






15 


The SS releases the RRC connection. 


- 


- 


- 


- 


16 


The SS reconfigures: 
Cell 1 as the "Serving cell". 
Cell 4 as a "Non-Suitable cell", 
Cell 2 as a " Suitable cell". 
Cell 3 as a " Suitable cell". 










17 


Check: Does the UE transmit the ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


5 


F 


18 


If possible (see ICS) switch off is performed. 
Otherwise the power is removed. 


- 


- 


- 


- 


19 


The UE is brought back to operation. 


- 


- 


- 


- 


20 


The following message is sent on Cell 1 . 


- 


- 


- 


- 


21 


Check: Does the UE transmit the ATTACH 


— > 


ATTACH REQUEST 


6 


P 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



458 



ETSI TS 136 523-1 V8.0.1 (2009-01) 





REQUEST message including a PDN 
CONNECTIVITY REQUEST message as 
specified? 










22 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






23 


The UE transmits an AUTHENTICATION 
RESPONSE message. 


— > 


AUTHENTICATION RESPONSE 


- 


- 


24 


The SS starts integrity protection and ciphering 


- 


- 


- 


- 


25 


The SS transmits an ATTACH ACCEPT 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT REQUEST 
message. 


<— 


ATTACH ACCEPT 






26 


The UE transmits an ATTACH COMPLETE 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 







9.2.1 .1 .14.3.3 Specific message contents 

Table 9.2.1.1.14.3.3-1: Message ATTACH REJECT (step 4, Table 9.2.1.1.14.3.2-1) 



Derivation path: 36.508 table 4.7.2.3 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


"No security 
protection" 




EMM cause 


00001100 


#12 "Tracking 
area not allowed" 




ESM message container 


Not present 







Table 9.2.1.1.14.3.3-2: Message ATTACH REQUEST (step 13 and 21 Table 9.2.1.1.14.3.2-1) 



Derivation path: 36.508 table 4.7.2.4 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUTI or IMSI 


IMSI1 


GUTI has been 
deleted after 
receiving 

ATTACH REJECT 
at step 4; only 
IMSI is available. 




Last visited registered TAI 


Not present 


TAI has been 
deleted after 
receiving 

ATTACH REJECT 
at step 4. 





9.2.1.1.19 
9.2.1.1.19.1 
(1) 



Attach / Abnormal case / Failure due to non integrity protection 
Test Purpose (TP) 



with { UE has not performed NAS security mode control procedure } 
ensure that { 

when { UE receives an ATTACH ACCEPT messages without NAS integrity protection } 
then { UE discards this message } 
} 

(2) 

with { a valid NAS security context exists and the NAS security mode control procedure has been 
successfully completed in the network and the UE } 
ensure that { 

when { UE receives a NAS signalling message without integrity protection } 
then { UE discards this NAS signalling message } 
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9.2.1 .1 .19.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 4.4.3.1, 
4.4.3.2 and 5.5.2.2.1. 

[TS 24.301, clause 4.4.3.1] 

Integrity protected signalling is mandatory for the NAS messages once a valid NAS security context exists and the NAS 
security mode control procedure has been successfully completed in the network and the UE. Integrity protection of all 
NAS signalling messages is the responsibility of the NAS layer. It is the network which activates integrity protection. 

[TS 24.301, clause 4.4.3.2] 

Except the messages listed below, no NAS signalling messages shall be processed by the receiving EMM entity or 
forwarded to the ESM entity, unless the NAS security mode control procedure has been successfully completed: 

EMM messages: 

- IDENTITY REQUEST (if requested identification parameter is IMSI); 

- AUTHENTICATION REQUEST; 

- AUTHENTICATION REJECT; 

- ATTACH REJECT; 

- DETACH REQUEST; 

- DETACH ACCEPT (for non switch off); 

- TRACKING AREA UPDATE REJECT; 

- SERVICE REJECT. 

NOTE: These messages are accepted by the UE without integrity protection, as in certain situations they are sent 
by the network before security can be activated. 

Editor's note: The messages in this list need to fulfil one or several SA3 requirement(s) as follows: the message may 
be sent before the security mode control procedure is performed, or when too much complexity would be 
involved if the message were received with integrity protection. 

Once integrity protection is activated, the receiving EMM or ESM entity in the UE shall not process any NAS 
signalling messages unless they have been successfully integrity checked by the NAS layer. If NAS signalling 
messages, having not successfully passed the integrity check, are received, then the NAS layer in the UE shall discard 
that message. If any NAS signalling message is received, as not integrity protected even though the integrity protection 
has been activated in the UE by the network, then the NAS layer shall discard this message. 

[TS 24.301, clause 5.5.2.2.1] 



If the UE is to be switched off, the UE shall try for a period of 5 seconds to send the DETACH REQUEST message. 
During this period, the UE may be switched off as soon as the DETACH REQUEST message has been sent. After 
transmission of the message, the UE shall delete the KSI, if any. 



9.2.1.1.19.3 Test description 

9.2.1.1.19.3.1 Pre-test conditions 

System Simulator: 
- CeUl 

ETSI 
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UE: 

- The test USIM contains GUTIl and TAIl, and EPS update status is "EUl: UPDATED". 

Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.2.1.1.19.3.2 



Test procedure sequence 



Table 9.2.1.1.19.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


The UE transmits an ATTACH REQUEST 
message including a PDN CONNECTIVITY 
REQUEST message. 

Note: The ATTACH REQUEST message 
shall be sent as a plain NAS message (see TS 
24.301 -clause 9.1). 


— > 


ATTACH REQUEST 






3 


The SS transmits an ATTACH ACCEPT 
although UE has not successfully completed 
any NAS security mode control procedure. 

Note: The ATTACH ACCEPT message is 
sent as a plain NAS message (see TS 24.301 
-clause 9.1). 


<— 


ATTACH ACCEPT 






4 


Check: Does the UE transmit an ATTACH 
COMPLETE message within the next 1s? 

Note: the UE discards ATTACH ACCEPT 
message without security protection 


— > 


ATTACH COMPLETE 


1 


F 


5 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






6 


The UE transmits an AUTHENTICATION 
RESPONSE message to establish mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






7 


The SS transmits a SECURITY MODE 
COMMAND message to activate NAS security. 


<— 


SECURITY MODE COMMAND 


- 


- 


8 


The UE transmits a SECURITY MODE 
COMPLETE message and establishes the 
initial security configuration. 


— > 


SECURITY MODE COMPLETE 






9 


The SS transmits an ATTACH ACCEPT 
without integrity protection. 

Note: The ATTACH ACCEPT message is sent 
as a plain NAS message (see TS 24.301 - 
clause 9.1). 


<— 


ATTACH ACCEPT 






10 


Check: Does the UE transmit an ATTACH 
COMPLETE message within the next 1s? 

Note: the UE discards ATTACH ACCEPT 
message without security protection 


— > 


ATTACH COMPLETE 


2 


F 


11 


The SS transmits an ATTACH ACCEPT 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT REQUEST. 
Note: The ATTACH ACCEPT message is sent 
as a security protected NAS message (see TS 
24.301 -clause 9.1). 

Nota 1 : SS allocates a PDN address of a PDN 
type which is compliant with from the PDN type 
requested by the UE. 


<— 


ATTACH ACCEPT 






12 


Check: Does the UE transmit an ATTACH 
COMPLETE message including a ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT 
message as specified? 

Note: The ATTACH COMPLETE message is 
sent as a security protected NAS message 
(see TS 24.301 -clause 9.1). 


— > 


ATTACH COMPLETE 


2 


P 


13 


The SS releases the RRC connection. 


- 


- 


- 


- 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



462 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



14 


Checl< : Does the test results of CALL generic 
procedure [18] indicate tliat tlie UE is in E- 
UTRA EMM-REGISTERED state with S- 
TMSI3? 

Note: This step verifies that the UE has 
dropped the GUTI2 which was included in the 
unprotected ATTACH ACCEPT messages. 






1,2 





9.2.1.1.19.3.3 Specific message contents 

Table 9.2.1.1.19.3.3-1: Message ATTACH ACCEPT (steps 3 and 9, Table 9.2.1.1.19.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 (Plain MAS message) 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


"no security 
protection" 




EPS attach result 


001 


"EPS only" 


NOT 

pc_CSfallb 

ack 




010 


"combined 


pc CSfallb 






EPS/IMSI attach" 


ack 


Spare half octet 


0000 






TAI list 




List of 3 TAIs 




Length of tracking area identity list contents 


12 






Number of elements 


3 






Type of list 


000 


One PLMN with 

non-consecutive 

TACs 




Partial tracking area identity list 


PLMN = PLMN1 


3 TACs including 






TAC1 = TAC1 


the TAI including 






TAC2 = TAC2 


"Last visited 






TAC3 = TAC3 


registered TAI" if 
present 




GUTI 


GUTI2 


The SS chooses a 
value different 
fromGUTII. 




Location area identification 


Not present 






MS identity 


Not Present 






EMM cause 


Not present 







Note: This message is voluntarily sent as a plain NAS message (see TS 24.301 - clause 9.1). 
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Table 9.2.1 .1 .1 9.3.3-2: Message ATTACH ACCEPT (step 1 1 , Table 9.2.1 .1 .19.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 (Security protected NAS message) 


Information Element 


Value/Remark 


Comment 


Condition 


Security header type 


0000 


"no security 
protection" 




EPS attach result 


001 


"EPS only" 


NOT 

pc_CSfallb 

ack 




010 


"combined 


pc_CSfallb 






EPS/IMSI attach" 


ack 


Spare half octet 


0000 






TAI list 




List of 3 TAIs 




Length of tracking area identity list contents 


12 






Number of elements 


3 






Type of list 


000 


One PLMN with 
non-consecutive 
TAGS 




Partial tracking area identity list 


PLMN = PLMN1 


3 TACs including 






TAC1 = TAC1 


the TAI including 






TAC2 = TAC2 


"Last visited 






TAC3 = TAC3 


registered TAI" if 
present 




GUTI 


GUTI3 


The SS chooses a 
value different 
from GUTI1 and 
GUTI2. 




Location area identification 


Not present 






IVIS identity 


Not Present 






EIVIM cause 


Not present 







9.2.1.2 
9.2.1.2.1 
9.2.1.2.1.1 
(1) 



Combined attach procedure for EPS services and non-EPS services 
Combined attach procedure / Success /EPS and non-EPS services 
Test Purpose (TP) 



with { UE in state EMM-DEREGISTERED and is switchecil off } 
ensure that { 

when { UE is powered up or switched on} 
then { UE sends ATTACH REQUEST message with EPS attach type IE 'combined EPS/IMSI attach' } 
} 

(2) 

with { UE in state EMM-REGISTERED- INITIATED} 
ensure that { 

when { UE receives ATTACH ACCEPT message with EPS attach result 'combined EPS/IMSI attach' } 
then { UE sends ATTACH COMPLETE message and enters EMM state EMM-REGISTERED and MM state MM- IDLE 
} 



9.2.1.2.1.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 24.301 clauses 
5.5.1.3.2, 5.5.1.3.4.1 and 5.5.1.3.4.2. 

[TS24.301clause5.5. 1.3.2] 

If the UE is in EMM state EMM-DEREGISTERED, the UE initiates the combined attach procedure by sending an 
ATTACH REQUEST message to the network, starting timer T3410 and entering state EMM-REGISTERED- 
INITIATED (see figure 5.5.1.2.2.1). 

The UE shall include a valid GUTI together with the last visited registered TAI in the ATTACH REQUEST message. If 
there is no valid GUTI available, the IMSI shall be included instead of the GUTI. 
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[TS24.301clause5.5. 1.3.4.1] 

Depending on the value of the EPS attach result IE received in the ATTACH ACCEPT message, two different cases 
can be distinguished: 

1) The EPS attach result IE value indicates "combined EPS/IMSI attach": attach for EPS and non-EPS services 
have been successful. 



[TS24.301clause5.5. 1.3.4.2] 

The description for attach for EPS services as specified in subclause 5.5.1.2.4 shall be followed. In addition, the 
following description for attach for non-EPS services applies. 

The TMSl reallocation may be part of the combined attach procedure. The TMSI allocated is then included in the 
ATTACH ACCEPT message, together with the location area identification (LAI). In this case the MME shall start timer 
T3450 and enter state EMM-COMMON -PROCEDURE-INITIATED as described in subclause 5.4.1. 

The UE, receiving an ATTACH ACCEPT message, stores the received location area identification, stops timer T3410, 
resets the location update attempt counter and sets the update status to Ul UPDATED. If the message contains a mobile 
identity, the MS shall use this mobile identity as the new temporary identity. The UE shall delete its old mobile identity 
and shall store the new mobile identity. If no mobile identity has been included by the network in the ATTACH 
ACCEPT message, the old mobile identity, if any available, shall be kept. The UE shall enter EMM state EMM- 
REGISTERED and MM state MM-IDLE. 

Upon receiving an ATTACH COMPLETE message, the MME shall stop timer T3450 and consider the new TMSI sent 
in the ATTACH ACCEPT message as valid. 

9.2.1.2.1.3 Test description 

9.2.1.2.1.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

- Cell 1 belongs to TAI-1(MCC1/MNC1/TAC1).. 

UE: 

- TheUEhasavalidGUTI(GUTI-l). 

Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.2.1.2.1.3.2 



Test procedure sequence 



Table 9.2.1.2.1.3.2-1: Main Behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is powered up or switched on. 






- 


- 


2 


The UE transmits ATTACH REQUEST 
message with a PDN CONNECTIVITY 
REQUEST message to request PDN 
connectivity to the default PDN. EPS attach 
type = "combined EPS/IMSI attach" 


— > 


ATTACH REQUEST 


1 


P 


3 


The SS starts an authentication procedure 


<— 


AUTHENTICATION REQUEST 


- 


- 


4 


The UE responds properly to the 
authentication procedure 


— > 


AUTHENTICATION RESPONSE 


- 


- 


5 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


6 


The UE responds properly to the NAS security 
mode command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


7 


The SS sends ATTACH ACCEPT message 
with the ACTIVATE DEFAULT EPS BEARER 
CONTEXT REQUEST message. 


<— 


ATTACH ACCEPT 






8 


Check: Does the UE send ATTACH 
COIVIPLETE message with the ACTIVATE 
DEFAULT EPS BEARER CONTEXT ACCEPT 
message. 


— > 


ATTACH COMPLETE 


2 


P 


9 


The SS releases the RRC connection. 






- 


- 


10 


The SS sends Paging message with S-TMSI2 
inGUTI-2totheUE. 


- 


- 


- 


- 


11 


Check: Does the UE initiates RRC Connection 
establishment? 


- 


- 


2 


P 


12 


The SS sends Paging message with TMSI-1 to 
the UE (FFS). 


<— 


Paging 


- 


- 


13 


Check: Does the UE perform CS fallback? 
(FFS) 






2 


P 



9.2.1 .2.1 .3.3 Specific message contents 

Editor's note: this subclause is not complete yet. 

Table 9.2.1.2.1.3.3-1 : Message ATTACH REQUEST (step 2, Table 9.2.1.2.1.3.2-1) 



Derivation path: 36.508 table xxx 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUTI or IMSI 


GUTI-1 






EPS attach type 


combined EPS/IMSI 
attach 







Table 9.2.1.2.1.3.3-2: Message ATTACH ACCEPT (step 7, Table 9.2.1.2.1.3.2-1) 



Derivation path: 36.508 table xxx 


Information Element 


Value/Remark 


Comment 


Condition 


EPS attach result 


combined EPS/IMSI 
attach 






GUTI 


GUTI-2 






LAI 


LAI-1 






MS identity 


TMSI-1 
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9.2.2 Detach procedure 

9.2.2.1 UE initiated detach procedure 

9.2.2.1 .1 UE initiated detach / UE switched off 

9.2.2.1.1.1 Test Purpose (TP) 
(1) 

with { UE in any EMM state } 
ensure that { 

when { the UE is switched off } 
then { the UE sends DETACH REQUEST message, deletes the KSI, if any, and deactivates the EPS 
bearer context (s) locally } 
} 

9.2.2.1 .1 .2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 24.301 clauses and 
5.5.2.2.1 and 5.5.2.2.2. 

[TS24.301 clause 5.5.2.2.1] 

The detach procedure is initiated by the UE by sending a DETACH REQUEST message. The Detach type IE included 
in the message indicates whether detach is due to a "switch off or not. The Detach type IE also indicates whether the 
detach is for EPS services only, for non-EPS services only, or for both. 



If the UE is to be switched off, the UE shall try for a period of 5 seconds to send the DETACH REQUEST message. 
During this period, the UE may be switched off as soon as the DETACH REQUEST message has been sent. After 
transmission of the message, the UE shall delete the KSI, if any. 

[TS24.301 clause 5.5.2.2.2] 

When the DETACH REQUEST message is received by the network, the network shall send a DETACH ACCEPT 
message to the UE, if the Detach type IE does not indicate "switch off". Otherwise, the procedure is completed when 
the network receives the DETACH REQUEST message. On reception of a DETACH REQUEST message indicating 
"switch off", the MME shall delete the KSI, if any. 

The network and the UE shall deactivate the EPS bearer context(s) for this UE locally without peer-to-peer signalling 
between the UE and the MME. 

The UE, when receiving the DETACH ACCEPT message, shall stop timer T3421. 

The UE is marked as inactive in the network for EPS services. State EMM-DEREGISTERED is entered in the UE and 
the network. 



9.2.2.1.1.3 


Test description 


9.2.2.1.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 
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Preamble: 

- The UE isin to EMM-REGISTERED state (State 2) according to [ 1 8] . 

Editor's note: No such state is defined, state 2 is "Registered, Idle mode". 

UE has a valid GUTI-1 and is registered in TAI-1 

Note: Detach due "switch off" can be done in any state but for testing purposes EMM-REGISTERED has been 
chosen as a representative state. 



9.2.2.1.1.3.2 



Test procedure sequence 

Table 9.2.2.1.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Cause switch off or remove power from the UE 










2 


Check: does the UE transmit a DETACH 
REQUEST with the Detach Type IE indicating 
"switch off"? 


— > 


DETACH REQUEST 


1 


P 


3 


Checl<: does the send any further DETACH 
REQUEST messages within the next 5s? 


— > 


DETACH REQUEST 


1 


F 


4 


The SS starts an authentication procedure 
using the previously allocated KSI 


<— 


AUTHENTICATION REQUEST 






5 


Check: does the UE transmit an 
AUTHENTICATION RESPONSE message 
within the next 6s? 


— > 


AUTHENTICATION RESPONSE 


1 


F 


6 


The SS starts the EPS bearer context 
modification procedure using the previously 
allocated EPS bearer identity 


<— 


MODIFY EPS BEARER 
CONTEXT REQUEST 






7 


Check: does the UE transmit a IVIODIFY EPS 
BEARER CONTEXT ACCEPT message within 
the next FFS s? 


— > 


MODIFY EPS BEARER 
CONTEXT ACCEPT 


1 


F 



9.2.2.1.1.3.3 
FFS. 



Specific message contents 



9.2.2.1.2 



UE initiated detach / USIM removed from the UE 



9.2.2.1.2.1 



Test Purpose (TP) 



(1) 

with { UE in any EMM state } 
ensure that { 

when { the USIM is removed from the UE } 
then { the UE sends DETACH REQUEST message and indicates that the detach is for both EPS services 
and non-EPS services | 



9.2.2.1.2.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 24.301 clauses and 
5.5.2.2.1 and 5.5.2.2.3. 

[TS24.301 clause 5.5.2.2.1] 

The detach procedure is initiated by the UE by sending a DETACH REQUEST message. The Detach type IE included 
in the message indicates whether detach is due to a "switch off or not. The Detach type IE also indicates whether the 
detach is for EPS services only, for non-EPS services only, or for both. 

If the detach is not due to switch off and the UE is in the state EMM-REGISTERED, timer T3421 shall be started in the 
UE after the DETACH REQUEST message has been sent. If the detach type indicates that the detach is for non-EPS 
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services only the UE shall enter the state EMM-REGISTERED.IMSI-DETACH-INITIATED, otherwise the UE shall 
enter the state EMM-DEREGISTERED-INITIATED. If the detach type indicates that the detach is for non-EPS 
services or both EPS and non-EPS services, the UE shall enter the state MM IMSI DETACH PENDING. 

[TS24.301 clause 5.5.2.2.3] 

When the DETACH REQUEST message is received by the network, a DETACH ACCEPT message shall be sent to the 
UE, if the Detach type IE value indicates that the detach request has not been sent due to switching off. Depending on 
the value of the Detach type IE the following applies: 

- combined EPS/IMSI detach: 

The UE is marked as inactive in the network for EPS and for non-EPS services. The states EMM- 
DEREGISTERED and MM-NULL are entered in both the UE and the network. 



9.2.2.1.2.3 
9.2.2.1.2.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1 (FDD or TDD). 

UE: 
None. 

Preamble: 

- UE is brought to EMM-REGISTERED state (State 2) according to [18] 
UE has a valid GUTI- 1 and is registered in TAI- 1 

Does UE support USIM removal without power down Y/N 

Note: Detach due "USIM removal" can be done in any state but for testing purposes EMM-REGISTERED has 
been chosen as a representative state. 



9.2.2.1.2.3.2 



Test procedure sequence 

Table 9.2.2.1.2.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 




U-S 


lUlessage 


1 


Cause removal of USIM from the UE without 
powering down 


- 


- 


- 


- 


2 


Check: does the UE transmit a DETACH 
REQUEST with the Detach Type IE indicating 
"normal detach" and "combined EPS/IIVISI 
detach"? 


— > 


DETACH REQUEST 


1 


P 


3 


SS responds with DETACH ACCEPT message 


<— 


DETACH ACCEPT 


- 


- 


4 


The SS starts a paging procedure using the 
previously allocated identifiers 


- 


- 


- 


- 


5 


Check: does the UE respond to the paging? 


~> 




1 


F 



9.2.2.1.2.3.3 
FFS. 



Specific message contents 
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9.2.2.2 Network initiated detach procedure 
9.2.2.2.1 NW initiated detach / re-attach required 

9.2.2.2.1 .1 Test Purpose (TP) 
(1) 

with { UE in EMM-REGISTERED state } 
ensure that { 

when { SS sends DETACH REQUEST message with the Detach type IE "re-attach required" } 
then { UE sends DETACH ACCEPT message and UE intiates an attach procedure } 
} 

9.2.2.2.1.2 Conformance requirements 

References: The conformance requirement covered in the present TC is specified in: 3GPP TS 24.301 clauses 5.5.2.3.2. 

[TS24.301 clause5.5.2.3.2] 

When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach required", the UE shall 
deactivate the EPS bearer context(s) including the default EPS bearer context locally without peer-to-peer signalling 
between the UE and the MME. The UE shall then send a DETACH ACCEPT message to the network and enter state 
EMM-DEREGISTERED. The UE shall, after the completion of the detach procedure, initiate an attach procedure, using 
the existing NAS signalling connection. 

A UE which receives a DETACH REQUEST message with detach type indicating "re-attach required" or "re-attach not 
required" and no cause code, is detached only for EPS services. 

If the detach type IE indicates "IMSI detach" or "re-attach required" then the UE shall ignore the cause code if received. 

9.2.2.2.1.3 Test description 

9.2.2.2.1.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 

- Cell 1 belongs to TAl-1 (MCCl/MNCl/TACl).. 

UE: 

- The UE has a valid GUTI (GUTI-1) and is registered in TAI-1 

Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 
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9.2.2.2.1.3.2 



Test procedure sequence 



Table 9.2.2.2.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 


U-S 


Message/PDU/SDU 


1 


The SS initiates Detach procedure with the 
Detach Type IE "re-attach required" 


<— 


DETACH REQUEST 


- 


- 


2 


Check: Does the UE send DETACH ACCEPT 
message? 


— > 


DETACH ACCEPT 


1 


P 


3 


Check: Does the UE send ATTACH 
REQUEST message with GUTI-1 and TAI-1 ? 


— > 


ATTACH REQUEST 


1 


P 


4 


The SS starts an authentication procedure 


<— 


AUTHENTICATION REQUEST 


- 


- 


5 


The UE responds properly to the 
authentication procedure 


— > 


AUTHENTICATION RESPONSE 


- 


- 


6 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


7 


The UE responds properly to the NAS security 
mode command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


8 


The SS sends ATTACH ACCEPT to assign the 
new GUTI (GUTI-2). 


<— 


ATTACH ACCEPT 


- 


- 


9 


Check: Does the UE send ATTACH 
COMPLETE message? 


— > 


ATTACH COMPLETE 


1 


P 


10 


The SS releases RRC connection. 


- 




- 


- 


11 


Check: Does the UE ignore paging on cell 1 
with S-TIVISn for PS domain? 


- 


- 


1 




12 


Check: Does the UE respond to paging on cell 
1 with S-TMSI2 for PS domain? 


- 




1 





9.2.2.2.1 .3.3 Specific message contents 

Table 9.2.2.2.1.3.3-1: Message DETACH REQUEST (step 1, Table 9.2.2.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 2 


Information Element 


Value/Remark 


Comment 


Condition 


Detach type 


'001'B 


"re-attach 
required" 





Table 9.2.2.2.1.3.3-2: Message ATTACH REQUEST (step 3, Table 9.2.2.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-4 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUTI or IMSI 


GUTI-1 







Table 9.2.2.2.1.3.3-3: Message ATTACH ACCEPT (step 8, Table 9.2.2.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 


Information Element 


Value/Remark 


Comment 


Condition 


TAI list 








Length of tracking area identity list contents 


'00001 OOO'B 


8 octets 




Number of elements 


'OOOOO'B 


1 element 




Type of list 


'OO'B 


"list of TACs 
belonging to one 
PLMN, with non- 
consecutive TAC 
values" 




Partial tracking area identity list 


TAI-1 






GUTI 


GUTI-2 
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9.2.2.2.4 NW initiated detach / re-attach not required / IMSI invalid 

9.2.2.2.4.1 Test Purpose (TP) 
(1) 

with { UE in EMM-REGISTERED state} 
ensure that { 

when { UE receives DETACH REQUEST message with the Detach type IE = 're-attach not required' and 
with the EMM cause IE = 'Illegal MS'} 

then { UE sends DETACH ACCEPT message } 
} 

(2) 

with { UE in EMM-DEREGISTERED state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE detects entering a new tracking area} 
then { UE does not send ATTACH REQUEST message } 
} 

(3) 

with { UE in Power off, in EMM-DEREGISTERED state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE is powered on or switched on} 
then { UE sends ATTACH REQUEST message } 
} 

9.2.2.2.4.2 Conformance requirements 

References: The conformance requirement covered in the present TC is specified in: 3GPP TS 24.301 clause 5.5.2.3.2. 
[TS24.301 clause5.5.2.3.2] 



When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach not required", the UE 
shall deactivate the EPS bearer context(s) including the EPS default bearer context locally without peer-to-peer 
signalling between the UE and the MME. The UE shall then send a DETACH ACCEPT message to the network and 
enter state EMM-DEREGISTERED. 



If the detach type IE indicates "re-attach not required", the UE shall take the following actions depending on the 
received EMM cause code: 

#3 (Illegal MS); 

#6 (Illegal ME); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the Ust of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported in the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number and the GMM parameters GMM state, RAI, P-TMSI, P-TMSI 
signature, GPRS ciphering key sequence number and GPRS update status as specified in 3GPP TS 24.008 [6] for 
the case when a DETACH REQUEST is received with this cause value and with detach type set to "re-attach not 
required". The USIM shall also be considered as invalid for non-EPS services until switching off or the UICC 
containing the USIM is removed. 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 



472 



ETSI TS 136 523-1 V8.0.1 (2009-01) 



9.2.2.2.4.3 
9.2.2.2.4.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1 and Cell 3 

- Cell 1 belongs to TAI-1(MCC1/MNC1/TAC1) 

- Cell 3 belongs to TAI-3(MCC1/MNC2/TAC1). 

Cell 1 is set to the "Serving cell" and Cell 3 is set to the "non-Suitable cell" 

UE: 

None. 

Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 

- UE has a valid GUTI (GUTI-1) and is registered in TAI-1 



9.2.2.2.4.3.2 



Test procedure sequence 



Table 9.2.2.2.4.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Cause the SS to initiate Detach procedure with 
the Detach Type IE "re-attach not required" 
and with EIVIM cause IE "Illegal MS" 


<— 


DETACH REQUEST 






2 


Check: Does the UE send DETACH ACCEPT 
message 


— > 


DETACH ACCEPT 


1 


P 


3 


The SS releases RRC connection. 






- 


- 


4 


Set the cell type of cell 1 to the "non-Suitable 
cell ". Set the cell type of cell 3 to the "Serving 
cell " 










5 


Check: Does the UE transmit ATTACH 
REQUEST message to SS in next 30sec. 


-> 


ATTACH REQUEST 


2 


F 


6 


The UE is powered off or switched off. 






- 


- 


7 


The UE is powered on or switched on. 






- 


- 


8 


Check: Does the UE send ATTACH 
REQUEST message with a PDN 
CQNNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN. 


— > 


ATTACH REQUEST 


3 


P 


9 


The SS starts an authentication procedure 


<— 


AUTHENTICATIQN REQUEST 


- 


- 


10 


The UE responds properly to the 
authentication procedure 


— > 


AUTHENTICATIQN RESPONSE 


- 


- 


11 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


12 


The UE responds properly to the NAS security 
mode command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


13 


The SS sends ATTACH ACCEPT message 
with the ACTIVATE DEFAULT EPS BEARER 
CQNTEXT REQUEST message. 


<— 


ATTACH ACCEPT 






14 


The UE sends ATTACH CQIVIPLETE message 
with the ACTIVATE DEFAULT EPS BEARER 
CQNTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 


3 


P 



Editor's note; The definitions for "Non-Suitable cell", "Suitable neighbour cell" and "Serving cell" are PES and 
should be specified in TS36.508. 
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9.2.2.2.4.3.3 Specific message contents 

Table 9.2.2.2.4.3.3-1 : Message DETACH REQUEST (step 1, Table 9.2.2.2.4.3.2-1) 

FFS 

Table 9.2.2.2.4.3.3-2: Message ATTACH REQUEST (step 8, Table 9.2.2.2.4.3.2-1) 



Derivation path: 36.508 table 4.7.2-4 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUT! or IMS! 


IMS! 







Table 9.2.2.2.4.3.3-3: Message ATTACH ACCEPT (step 13, Table 9.2.2.2.4.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 


Information Element 


Value/Remark 


Comment 


Condition 


TAI list 


TAI-3 






GUT! 


GUTI-3 







9.2.2.2.6 



Detach / re-attach not required / GPRS services not allowed 



9.2.2.2.6.1 



Test Purpose (TP) 



(1) 



with { UE in EMM-REGISTERED state} 
ensure that { 

when { UE receives DETACH REQUEST message with the Detach type IE 
with the EMM cause IE = 'GPRS services not allowed'} 
then { UE sends DETACH ACCEPT message } 



're-attach not required' and 



(2) 

with { UE in EMM-DEREGISTERED state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE detects entering a new tracking area} 
then { UE does not send ATTACH REQUEST message } 
} 

(3) 

with { UE in Power off, in EMM-DEREGISTERED state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE is powered on or switched on} 
then { UE sends ATTACH REQUEST message } 
} 

9.2.2.2.6.2 Conformance requirements 

References: The conformance requirement covered in the present TC is specified in: 3GPP TS 24.301 clauses 5.5.2.3.2. 

[TS24.301 clause5.5.2.3.2] 



When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach not required", the UE 
shall deactivate the EPS bearer context(s) including the EPS default bearer context locally without peer-to-peer 
signalling between the UE and the MME. The UE shall then send a DETACH ACCEPT message to the network and 
enter state EMM-DEREGISTERED. 



If the detach type IE indicates "re-attach not required", the UE shall take the following actions depending on the 
received EMM cause code: 
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#7 (GPRS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported in the UE, the UE shall handle the GMM parameters GMM state, RAI, P 
TMSI, P-TMSI signature, GPRS ciphering key sequence number and GPRS update status as specified in 3GPP 
TS 24.008 [6] for the case when a DETACH REQUEST is received with this cause value and with detach type 
set to "re-attach not required". 

9.2.2.2.6.3 Test description 

9.2.2.2.6.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 and Cell 3 

- Cell 1 belongs to TAI-1(MCC1/MNC1/TAC1) 

- Cell 3 belongs to TAI-3(MCC1/MNC2/TAC1). 

- Cell 1 is set to the "Serving cell" and Cell 3 is set to the "non-Suitable cell" 

UE: 

- The UE has a valid GUTI (GUTI-1) and is registered in TAI-1 

- If pc_CSfallback, the UE has a vahd TMSI (TMSI-1) and is registered in LAI-1. 

Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 
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9.2.2.2.6.3.2 



Test procedure sequence 



Table 9.2.2.2.6.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a DETACH REQUEST with 
Detach Type "re-attach not required" and with 
ElVIIVI cause IE "GPRS services not allowed" 


<— 


DETACH REQUEST 






2 


Check: Does the UE transmit a DETACH 
ACCEPT message? 


— > 


DETACH ACCEPT 


1 


P 


3 


The SS releases RRC connection. 






- 


- 




EXCEPTION: Steps 4a1 to 4a2 describe 
behaviour that depends on the UE capability; 
the "lower case letter" identifies a step 
sequence that tal<e place if a capability is 
supported 










4a1 


IF pc CSfallback, the SS transmits a Paging 
message with TIVISI-I to the UE. (FFS) 


<— 


Paging 


- 


- 


4a2 


Check: Does the UE perform CS fallback 
(FFS)? 


- 


- 


1 


P 


5 


Set the cell type of cell 1 to the "non-Suitable 
cell ". Set the cell type of cell 3 to the "Serving 
cell " 










6 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


-> 


ATTACH REQUEST 


2 


F 


7 


The UE is powered off or switched off. 


- 


- 


- 


- 


8 


The UE is powered on or switched on. 


- 


- 


- 


- 


9 


Check: Does the UE transmit an ATTACH 
REQUEST message with a PDN 
CONNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN? 


— > 


ATTACH REQUEST 


3 


P 


10 


The SS starts an authentication procedure 


<— 


AUTHENTICATION REQUEST 


- 


- 


11 


The UE responds properly to the 
authentication procedure 


— > 


AUTHENTICATION RESPONSE 


- 


- 


12 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


13 


The UE responds to the NAS security mode 
command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


14 


The SS transmits an ATTACH ACCEPT 
message with the ACTIVATE DEFAULT EPS 
BEARER CONTEXT REQUEST message. 


<— 


ATTACH ACCEPT 






15 


The UE transmits an ATTACH COMPLETE 
message with the ACTIVATE DEFAULT EPS 
BEARER CONTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 







Editor's note: The definitions for "Non-Suitable cell", "Suitable neighbour cell" and "Serving cell" are FFS and 
should be specified in TS36.508. 

Editor's note: In step 6, there is no requirement for a UE to transmit an ATTACH REQUEST message within 30s. 

9.2.2.2.6.3.3 Specific message contents 

Table 9.2.2.2.6.3.3-1 : Message DETACH REQUEST (step 1, Table 9.2.2.2.6.3.2-1) 

FFS 

Table 9.2.2.2.6.3.3-2: Message ATTACH REQUEST (step 8, Table 9.2.2.2.6.3.2-1) 



Derivation path: 36.508 table 4.7.2-4 | 


Information Element 


Value/Remark 


Comment 


Condition 


OldGUTIorlMSI 


IMSI 
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Table 9.2.2.2.6.3.3-3: Message ATTACH ACCEPT (step 13, Table 9.2.2.2.6.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 


Information Element 


Value/Remark 


Comment 


Condition 


TAI list 


TAI-3 






GUT! 


GUTI-3 







9.2.2.2.7 Detach / re-attach not required / GPRS services and non-GPRS services not 

allowed 



9.2.2.2.7.1 



Test Purpose (IP) 



(1) 

with { UE in EMM-REGISTERED state} 
ensure that { 

when { UE receives DETACH REQUEST message with the Detach type IE = 're-attach not required' and 
with the EMM cause IE = 'GPRS services and non-GPRS services not allowed'} 
then { UE sends DETACH ACCEPT message } 
} 

(2) 

with { UE in EMM-DEREGISTERED state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE detects entering a new tracking area} 
then { UE does not send ATTACH REQUEST message } 
} 

(3) 

with { UE in Power off, in EMM-DEREGISTERED state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE is powered on or switched on} 
then { UE sends ATTACH REQUEST message } 
} 

9.2.2.2.7.2 Conformance requirements 

References: The conformance requirement covered in the present TC is specified in: 3GPP TS 24.301 clauses 5.5.2.3.2. 

[TS24.301 clause5.5.2.3.2] 



When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach not required", the UE 
shall deactivate the EPS bearer context(s) including the EPS default bearer context locally without peer-to-peer 
signalling between the UE and the MME. The UE shall then send a DETACH ACCEPT message to the network and 
enter state EMM-DEREGISTERED. 



If the detach type IE indicates "re-attach not required", the UE shall take the following actions depending on the 
received EMM cause code: 



#8 (GPRS services and non-GPRS services not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAI, TAI list and KSI. The UE shall 
consider the USIM as invalid for EPS services until switching off or the UICC containing the USIM is removed. 
The UE shall delete the list of equivalent PLMNs and shall enter the state EMM-DEREGISTERED. 

If A/Gb mode or lu mode is supported in the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number and the GMM parameters GMM state, RAI, P-TMSI, P-TMSI 
signature, GPRS ciphering key sequence number and GPRS update status as specified in 3GPP TS 24.008 [6] for 
the case when a DETACH REQUEST is received with this cause value and with detach type set to "re-attach not 
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required". The USIM shall also be considered as invalid for non-EPS services until switching off or the UICC 
containing the USIM is removed. 



9.2.2.2.7.3 
9.2.2.2.7.3.1 



Test description 
Pre-test conditions 



System Simulator: 

- Cell 1 and Cell 3 

- Cell 1 belongs to TAI-1(MCC1/MNC1/TAC1) 

- Cell 3 belongs to TAI-3(MCC1/MNC2/TAC1). 

- Cell 1 is set to the "Serving cell" and Cell 3 is set to the "non-Suitable cell" 



UE: 



The UE has a valid GUTI (GUTI-1), a valid TMSI (TMSI-1) and is registered in TAI-1 and LAI-1 



Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 



9.2.2.2.7.3.2 



Test procedure sequence 



Table 9.2.2.2.7.3.2-1 : Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a DETACH REQUEST 
message with the Detach Type IE 're-attach 
not required' and with EMM cause IE 'GPRS 
services and non-GPRS services not allowed' 


<— 


DETACH REQUEST 






2 


Check: Does the UE send DETACH ACCEPT 
message? 


— > 


DETACH ACCEPT 


1 


P 


3 


The SS releases RRC connection. 






- 


- 


4 


Set the cell type of cell 1 to the "non-Suitable 
cell ". Set the cell type of cell 3 to the "Serving 
cell " 










5 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


2 


F 


6 


The UE is powered off or switched off. 






- 


- 


7 


The UE is powered on or switched on. 






- 


- 


8 


Check: Does the UE transmit an ATTACH 
REQUEST message with a PDN 
CQNNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN? 


— > 


ATTACH REQUEST 


3 


P 


9 


The SS starts an authentication procedure 


<— 


AUTHENTICATIQN REQUEST 


- 


- 


10 


The UE responds properly to the 
authentication procedure 


— > 


AUTHENTICATIQN RESPONSE 


- 


- 


11 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MQDE COMMAND 


- 


- 


12 


The UE responds properly to the NAS security 
mode command procedure 


— > 


SECURITY MQDE CQMPLETE 


- 


- 


13 


The SS transmits ATTACH ACCEPT message 
with the ACTIVATE DEFAULT EPS BEARER 
CQNTEXT REQUEST message. 


<— 


ATTACH ACCEPT 






14 


The UE transmits an ATTACH CQMPLETE 
message with the ACTIVATE DEFAULT EPS 
BEARER CQNTEXT ACCEPT message. 


— > 


ATTACH CQMPLETE 


3 


P 
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Editor's note: The definitions for "Non-Suitable cell", "Suitable neighbour cell" and "Serving cell" are FFS and 
should be specified in TS36.508. 

Editor's note: In step 5, there is no requirement for a UE to transmit an ATTACH REQUEST message within 30s. 

9.2.2.2.7.3.3 Specific message contents 

Table 9.2.2.2.7.3.3-1 : Message DETACH REQUEST (step 1, Table 9.2.2.2.7.3.2-1) 



FFS 



Table 9.2.2.2.7.3.3-2: Message ATTACH REQUEST (step 8, Table 9.2.2.2.7.3.2-1) 



Derivation path: 36.508 table 4.7.2-4 | 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUT! or IMS! 


IMS! 







Table 9.2.2.2.7.3.3-3: Message ATTACH ACCEPT (step 13, Table 9.2.2.2.7.3.2-1) 



Derivation path: 36.508 table 4.7.2-4 | 


Information Element 


Value/Remark 


Comment 


Condition 


EPS attach result 


combined EPS/IMS! 
attach 






TAI list 


TAI-3 






GUT! 


GUTI-3 






LAI 


LAI-3 






MS identity 


TMSI-3 







9.2.2.2.8 
9.2.2.2.8.1 

(1) 



Detach / re-attach not required / PLMN not allowed 
Test Purpose (IP) 



with { UE in EMM-REGISTERED state} 
ensure that { 

when { UE receives DETACH REQUEST message with the Detach type IE 
with the EMM cause IE = 'PLMN not allowed'} 
then { UE sends DETACH ACCEPT message } 



're-attach not required' and 



(2) 

with { UE in EMM-DEREGISTERED . PLMN-SEARCH state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE detects entering the same PLMN identity} 
then { UE does not send ATTACH REQUEST message } 
} 

(3) 

with { UE in EMM-DEREGISTERED . PLMN-SEARCH state and in EU3 ROAMING NOT ALLOWED status} 
ensure that { 

when { UE detects entering a new PLMN identity } 
then { UE sends ATTACH REQUEST message } 
} 

(4) 

with { UE in EMM-REGISTERED state } 
ensure that { 

when { UE detects the PLMN identity which is stored by the UE in the 'forbidden PLMN list' 
then { UE does not send TRACKING AREA UPDATE REQUEST message } 
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9.2.2.2.8.2 Conformance requirements 

References: The conformance requirement covered in the present TC is specified in: 3GPP TS 24.301 clause 5.5.2.3.2. 

[TS24.301 clause5.5.2.3.2] 



When receiving the DETACH REQUEST message and the Detach type IE indicates "re-attach not required", the UE 
shall deactivate the EPS bearer context(s) including the EPS default bearer context locally without peer-to-peer 
signalling between the UE and the MME. The UE shall then send a DETACH ACCEPT message to the network and 
enter state EMM-DEREGISTERED. 



If the detach type IE indicates "re-attach not required", the UE shall take the following actions depending on the 
received EMM cause code: 



#1 1 (PLMN not allowed); 

The UE shall set the EPS update status to EU3 ROAMING NOT ALLOWED (and shall store it according to 
subclause 5.1.3.3) and shall delete any GUTI, last visited registered TAl, TAI list and KSI. The UE shall delete 
the list of equivalent PLMNs and enter the state EMM-DEREGISTERED.PLMN-SEARCH. 

The UE shall store the PLMN identity in the "forbidden PLMN list". 

The UE shall perform a PLMN selection according to 3GPP TS 23.122 [3]. 

If A/Gb mode or lu mode is supported in the UE, the UE shall handle the MM parameters update status, TMSI, 
LAI and ciphering key sequence number and the GMM parameters GMM state, RAI, P-TMSI, P-TMSI 
signature, GPRS ciphering key sequence number and GPRS update status as specified in 3GPP TS 24.008 [6] for 
the case when a DETACH REQUEST is received with this cause value and with detach type set to "re-attach not 
required". 

9.2.2.2.8.3 Test description 

9.2.2.2.8.3.1 Pre-test conditions 

System Simulator: 

- Cell 1, Cell 2 and Cell 3: 

- Cell 1 belongs to TAI-1(MCC1/MNC1/TAC1), 

- Cell 2 belongs to TAI-2(MCC1/MNC1/TAC2) 

- Cell 3 belongs to TAI-3(MCC1/MNC2/TAC1). 

- Cell 1 is set to the "Serving cell". Cell 2 and Cell 3 are set to the "non-Suitable cell" 

UE: 

- The UE has a valid GUTI (GUTI-1) and is registered in TAl-1 

- The UE does not store any PLMN identities in the "forbidden PLMN list". 

Preamble: 

The UE is in state Generic RB established (state 3) on Cell 1 according to [18]. 
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9.2.2.2.8.3.2 



Test procedure sequence 



Table 9.2.2.2.8.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The SS transmits a DETACH REQUEST 
message with the Detach Type IE "re-attach 
not required" and with EMIVI cause IE "PLIVIN 
not allowed" 


<— 


DETACH REQUEST 






2 


Check: Does the UE transmit a DETACH 
ACCEPT message? 


-> 


DETACH ACCEPT 


1 


P 


3 


The SS releases RRC connection. 






- 


- 


4 


Set the cell type of cell 1 to the "non-Suitable 
cell ". Set the cell type of cell 2 to the "Serving 
cell " 










5 


Check: Does the UE transmit an ATTACH 
REQUEST message in the next 30 seconds? 


— > 


ATTACH REQUEST 


2 


F 


6 


Set the cell type of cell 2 to the "Serving cell ". 
Set the cell type of cell 3 to the "Suitable 
neighbour cell " 










7 


Check: Does the UE transmit an ATTACH 
REQUEST message with a PDN 
CQNNECTIVITY REQUEST message to 
request PDN connectivity to the default PDN to 
Cell 3. 


— > 


ATTACH REQUEST 


3 


P 


8 


The SS starts an authentication procedure 


<— 


AUTHENTICATION REQUEST 


- 


- 


9 


The UE responds properly to the 
authentication procedure 


— > 


AUTHENTICATION RESPONSE 


- 


- 


10 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY IVIODE COMMAND 


- 


- 


11 


The UE responds properly to the NAS security 
mode command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


12 


The SS transmits an ATTACH ACCEPT 
message with the ACTIVATE DEFAULT EPS 
BEARER CONTEXT REQUEST message. 


<— 


ATTACH ACCEPT 






13 


The UE transmits an ATTACH COMPLETE 
message with the ACTIVATE DEFAULT EPS 
BEARER CONTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 


3 


P 


14 


The SS releases the RRC connection. 






- 


- 


15 


Set the cell type of cell 3 to the "non-Suitable 
cell ". Set the cell type of cell 2 to the "Serving 
cell " 










16 


Check: Does the UE transmit a TRACKING 
AREA UPDATE REQUEST message on Cell 2 
in the next 30 seconds? 


-> 


TRACKING AREA UPDATE 
REQUEST 


4 


F 



Editor's note: The definitions for "Non-Suitable cell", "Suitable neighbour cell" and "Serving cell" are FFS and 
should be specified in TS36.508. 

Editor's note: In step 5, there is no requirement for a UE to transmit an ATTACH REQUEST message within 30s. 

Editor's note: In step 16, there is no requirement for a UE to transmit a TRACKING AREA UPDATE message 
within 30s. 

9.2.2.2.8.3.3 Specific message contents 

Table 9.2.2.2.8.3.3-1 : Message DETACH REQUEST (step 1, Table 9.2.2.2.8.3.2-1) 

FFS 
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Table 9.2.2.2.8.3.3-2: Message ATTACH REQUEST (step 7, Table 9.2.2.2.8.3.2-1) 



Derivation path: 36.508 table 4.7.2-4 


Information Element 


Value/Remark 


Comment 


Condition 


Old GUT! or IMS! 


IMS! 







Table 9.2.2.2.7.3.3-3: Message ATTACH ACCEPT (step 12, Table 9.2.2.2.8.3.2-1) 



Derivation path: 36.508 table 4.7.2-1 


Information Element 


Value/Remark 


Comment 


Condition 


TAI list 


TAI-3 






GUT! 


GUTI-3 







9.2.3 Tracking area updating procedure (S1 mode only) 

9.2.3.1 Normal and periodic tracking area updating 

9.2.3.1 .1 Normal tracking area update / accepted 

9.2.3.1.1.1 Test Purpose (TP) 

(1) 

with { UE in state EMM-REGISTERED and EMM- IDLE mode} 
ensure that { 

when { UE detects entering a new tracking area already included in the TAI list } 
then { UE does not send TRACKING AREA UPDATE REQUEST message } 
} 

(2) 

with { UE in state EMM-REGISTERED and EMM- IDLE mode} 
ensure that { 

when { UE detects entering a new tracking area not included in the TAI list } 
then { UE sends TRACKING AREA UPDATE REQUEST message with "EPS update type = TA updating" 



9.2.3.1.1.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 24.301 clauses 5.5.3.1, 
5.5.3.2.2 and 5.5.3.2.4. 

[TS24.301 clause5.5.3.1] 

The tracking area updating procedure is always initiated by the UE and is used for the following purposes: 

- normal tracking area updating to update the registration of the actual tracking area of a UE in the network; 



[TS24.301 clause5.5.3.2.2] 

The UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING 
AREA UPDATE REQUEST message to the MME, 

i) when the UE detects entering a tracking area that is not in the list of tracking areas that the UE previously 
registered in the MME; 



After sending the TRACKING AREA UPDATE REQUEST message to the MME, the UE shall start timer T3430 and 
enter state EMM-TRACKING-AREA-UPDATING-INITIATED (see figure 5.5.3.2.2). If timer T3402 is currently 
running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer T341 1. 
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In the TRACKING AREA UPDATE REQUEST message the UE shall include a GUTI and the last visited registered 
TAI, the update type indicating the type of the tracking area updating. If the UE's TIN indicates "P-TMSI" the UE shall 
map the valid P-TMSI and RAI into the old GUTI. If a UE in EMM-IDLE mode has uplink user data pending when it 
initiates the tracking area updating procedure, or uplink signalling not related to the tracking area updating procedure, it 
may also set an "active" flag in the TRACKING AREA UPDATE REQUEST message to indicate the request to 
establish the user plane to the network and to keep the NAS signalling connection after the completion of the tracking 
area updating procedure. 

When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an EPS bearer 
context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS bearer contexts are 
active in the UE. 

[TS24.301 clause5.5.3.2.4] 



Upon receiving a TRACKING AREA UPDATE ACCEPT message, the UE shall stop timer T3430, reset the routing 
area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EUl UPDATED. If the 
message contains a GUTI, the UE shall use this GUTI as new temporary identity for EPS services and shall store the 
new GUTI. If no GUTI was included by the MME in the TRACKING AREA UPDATE ACCEPT message, the old 
GUTI shall be used. If the UE receives a new TAI list in the TRACKING AREA UPDATE ACCEPT message, the UE 
shall consider the new TAI list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAI list 
as valid. 



If the TRACKING AREA UPDATE ACCEPT message contained a GUTI, the UE shall return a TRACKING AREA 
UPDATE COMPLETE message to the MME to acknowledge the received GUTI. 

9.2.3.1.1.3 Test description 

9.2.3.1.1.3.1 Pre-test conditions 

System Simulator: 

- Celll,Cell2andCell4 

- Cell 1 belongs to TAI-1, Cell2 belongs to TAI-2 and CeU4 belongs to TAI-4. 

UE: 

None. 

Preamble: 

- The UE shall be in state EMM-DEREGISTERED. 

Editor's note: The preamble clause should refer to a state according to TS 36.508. 
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9.2.3.1.1.3.2 



Test procedure sequence 



Table 9.2.3.1.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 




The following messages are sent and shall be 
received on cell 1 . 






- 


- 


1 


Set the cell type of cell 1 to the "Serving cell". 
Set the cell type of cell 2 to the "Suitable 
neighbour cell". Set the cell type of cell 4 to the 
"Suitable neighbour cell" 










2 


The UE is powered up or switched on. 






- 


- 


3 


The UE transmits ATTACH REQUEST 
message with a PDN CONNECTIVITY 
REQUEST message to request PDN 
connectivity to the default PDN 


— > 


ATTACH REQUEST 






4 


The SS starts an authentication procedure 


<— 


AUTHENTICATION REQUEST 


- 


- 


5 


The UE responds to the authentication 
procedure 


— > 


AUTHENTICATION RESPONSE 


- 


- 


6 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


7 


The UE responds to the NAS security mode 
command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


8 


The SS sends ATTACH ACCEPT message 
with the ACTIVATE DEFAULT EPS BEARER 
CQNTEXT REQUEST message. EPS Attach 
result = 'EPS only'. GUTI = 'GUTI-1'. TAI list = 
'TAI-1 and TAI-2' 


<— 


ATTACH ACCEPT 






9 


The UE sends ATTACH COMPLETE message 
with the ACTIVATE DEFAULT EPS BEARER 
CQNTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 






10 


The SS releases the RRC connection. 






- 


- 


11 


Set the cell type of cell 1 to the "non-Suitable 
cell". Set the cell type of cell 2 to the "Serving 
cell" 










12 


Check: Does the UE transmit a TRACKING 
AREA UPDATE REQUEST message in the 
next 30 seconds? 






1 


F 




The following messages are sent and shall be 
received on cell 4. 






- 


- 


13 


Set the cell type of cell 2 to the " non-Suitable 
cell ". Set the cell type of cell 4 to the " Serving 
cell" 










14 


Check: Does the UE transmit a TRACKING 
AREA UPDATE REQUEST message? EPS 
update type = 'TA updating'. GUTI = 'GUTI-1'. 
Last visited registered TAI = 'TAI-2' 


— > 


TRACKING AREA UPDATE 
REQUEST 


2 


P 


15 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


16 


The UE responds to the NAS security mode 
command procedure. 


— > 


SECURITY MODE COMPLETE 


- 


- 


17 


The SS transmits a TRACKING AREA 
UPDATE ACCEPT message. EPS update 
result = 'TA only'. GUTI = 'GUTI-2'. TAI list = 
'TAI-4' 


<— 


TRACKING AREA UPDATE 
ACCEPT 






18 


Check: Does the UE transmit a TRACKING 
AREA UPDATE COMPLETE message? 


— > 


TRACKING AREA UPDATE 
COMPLETE 


2 


P 


19 


The SS releases the RRC connection. 






- 


- 


20 


The SS sends a Paging message with S- 
TMSI2 associated with GUTI-2. 


- 


- 


- 


- 


21 


Check: Does the UE initiates RRC Connection 
establishment? 






2 


P 
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Editor's note: For each test step with transmission of a NAS message, the differences compared with the defauh 
message contents as defined in 36.508 shall be specified as specific message contents. Then, the related 
information in the procedure description should be removed. 

Editor's note; The definitions for "Non-Suitable cell", "Suitable neighbour cell" and "Serving cell" are FES and 
should be specified in TS36.508. 

9.2.3.1 .1 .3.3 Specific message contents 

Editor's note: See editor's note in previous subclause. 



9.2.3.1 .2 Normal tracking area update / accepted / "Active" flag set 

9.2.3.1 .2.1 Test Purpose (TP) 
(1) 

with { UE in state EMM-SERVICE-REQUEST-INITIATED and EMM- CONNECTED} 
ensure that { 

when { UE detects entering a new tracking area already not included in the TAI list } 
then { UE sends TRACKING AREA UPDATE REQUEST message } 
} 

(2) 

with { UE in state EMM-REGISTERED and EMM- CONNECTED} 
ensure that { 

when { UE sends TRACKING AREA UPDATE COMPLETE to NW } 
then { UE establishes the user plane and keeps the NAS signalling connection } 
} 

9.2.3.1.2.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: 3GPP TS 24.301 clauses 5.5.3.1, 
5.5.3.2.2, 5.5.3.2.4 and 5.6.1.5. 

[TS24.301 clause5.5.3.1] 

The tracking area updating procedure is always initiated by the UE and is used for the following purposes: 

normal tracking area updating to update the registration of the actual tracking area of a UE in the network; 

[TS24.301 clause5.5. 3.2.2] 

The UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING 
AREA UPDATE REQUEST message to the MME, 

i) when the UE detects entering a tracking area that is not in the list of tracking areas that the UE previously 
registered in the MME; 



After sending the TRACKING AREA UPDATE REQUEST message to the MME, the UE shall stait timer T3430 and 
enter state EMM-TRACKING-AREA-UPDATING-INITIATED (see figure 5.5.3.2.2). If timer T3402 is currently 
running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer T341 1. 

In the TRACKING AREA UPDATE REQUEST message the UE shall include a GUTI and the last visited registered 
TAI, the update type indicating the type of the tracking area updating. If the UE's TIN indicates "P-TMSI" the UE shall 
map the valid P-TMSI and RAI into the old GUTI. If a UE in EMM-IDLE mode has uplink user data pending when it 
initiates the tracking area updating procedure, or uplink signalling not related to the tracking area updating procedure, it 
may also set an "active" flag in the TRACKING AREA UPDATE REQUEST message to indicate the request to 
establish the user plane to the network and to keep the NAS signalling connection after the completion of the tracking 
area updating procedure. 
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When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an EPS bearer 
context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS bearer contexts are 
active in the UE. 

[TS24.301 clause5.5.3.2.4] 



If the "active" flag is included in the TRACKING AREA UPDATE REQUEST message, the MME shall re-establish 
the radio and SI bearers for all active EPS bearer contexts. 

Upon receiving a TRACKING AREA UPDATE ACCEPT message, the UE shall stop timer T3430, reset the tracking 
area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EUl UPDATED. If the 
message contains a GUTI, the UE shall use this GUTI as new temporary identity for EPS services and shall store the 
new GUTI. If no GUTI was included by the MME in the TRACKING AREA UPDATE ACCEPT message, the old 
GUTI shall be used. If the UE receives a new TAI list in the TRACKING AREA UPDATE ACCEPT message, the UE 
shall consider the new TAI list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAI list 
as valid. 



If the TRACKING AREA UPDATE ACCEPT message contained a GUTI, the UE shall return a TRACKING AREA 
UPDATE COMPLETE message to the MME to acknowledge the received GUTI. 



[TS24.301clause5.6.1.5] 



e) Tracking area updating procedure is triggered 

The UE shall abort the service request procedure, stop timer T3417 and perform the tracking area updating 
procedure. The "active" flag shall be set in the TRACKING AREA UPDATE REQUEST message. 



j) Transmission failure of SERVICE REQUEST message indication with TAI change from lower layers 

If the current TAI is not in the TAI list, the service request procedure shall be aborted to perform the tracking 
area updating procedure. The "active" flag shall be set in the TRACKING AREA UPDATE REQUEST 

message. 

If the current TAI is still part of the TAI list, the UE shall restart the service request procedure. 



9.2.3.1.2.3 Test description 

9.2.3.1.2.3.1 Pre-test conditions 

System Simulator: 

- CellA(TAI-l:MCCl/MNCl/TACl) 

- Cell B(TAI-2:MCC1/MNC1/TAC2) 

- Cell A is set to the "Serving cell" and Cell B is set to the "Non-suitable cell". 

UE: 

- The UE has a valid GUTI (GUTI- 1 ) and is registered on TAI- 1 . 
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Preamble: 

The UE is in state Registered, Idle Mode (state 2) on Cell A according to [18]. 



9.2.3.1.2.3.2 



Test procedure sequence 



Table 9.2.3.1.2.3.2-1: Main behaviour 



St 


Procedure 


lUlessage Sequence 


TP 


Verdict 




U-S 


lUlessage 


1 


Force the UE to initiate uplink user 
data.(Notel) 


- 


- 


- 


- 


2 


The UE transmits SERVICE REQUEST 
message. 


— > 


SERVICE REQUEST 


- 


- 


3 


The SS does not perform a radio bearer 
establishment procedure. {Note2) 


- 


- 


- 


- 




The following messages are sent and shall be 
received on cell B. 






- 


- 


4 


Set the cell type of cell A to the "Non-suitable 
cell". Set the cell type of cell B to the "Serving 
cell". 










5 


Check: Does the UE transmit a TRACKING 
AREA UPDATE REQUEST message with 
"Active" flag? 


— > 


TRACKING AREA UPDATE 
REQUEST 


1 


P 


7 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


8 


The UE responds to the NAS security mode 
command procedure. 


— > 


SECURITY MODE COMPLETE 


- 


- 


9 


The SS transmits a TRACKING AREA 
UPDATE ACCEPT message. 


<— 


TRACKING AREA UPDATE 
ACCEPT 


- 


- 


10 


Check: Does the UE transmit a TRACKING 
AREA UPDATE COMPLETE message? 


— > 


TRACKING AREA UPDATE 
COMPLETE 


1 


P 


11 


The SS waits lOseconds {T3440). 










12 


Check: does the test result of the above 
procedure indicate that UE is in 
EMM CONNECTED state?(FFS) 






2 


P 


Note1 : This could be done by e.g. IVIMI or by AT command. 
Note2: The SS does not send any AS or NAS messages to UE. 



9.2.3.1 .2.3.3 Specific message contents 

Table 9.2.3.1.2.3.3-1 : Message TRACKING AREA UPDATE REQUEST (step 3, Table 9.2.3.1.2.3.2-1) 



Derivation path: 36.508 table 4.7.2-27 


Information Element 


Value/Remark 


Comment 


Condition 


EPS update type 








"Active" flag 


'1'B 


Bearer 

establishment 

requested 




EPS update type value 


'OOO'B 


"TA updating" 




Old GUTI 


GUTI-1 


Old GUTI is 
included by UE if 
valid, IMSI 
otherwise. 
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Table 9.2.3.1.2.3.3-2: Message TRACKING AREA UPDATE ACCEPT (step 6, Table 9.2.3.1.2.3.2-1) 



Derivation path: 36.508 table 4.7.2-24 


Information Element 


Value/Remark 


Comment 


Condition 


EPS update result 


'OOO'B 


"TA updated" 




GUT! 


GUTI-2 






TAI list 








Length of tracking area identity list contents 


'00001 OOO'B 


8 octets 




Number of elements 


'OOOOO'B 


1 element 




Type of list 


'OO'B 


"list of TAGS 
belonging to one 
PLIVIN, with non- 
consecutive TAG 
values" 




Partial tracking area identity list 


TAI-2 







9.2.3.1.5 



Periodic tracking area update / accepted 



9.2.3.1.5.1 



Test Purpose (TP) 



(1) 

with { UE in state EMM-REGISTERED and EMM- IDLE mode} 
ensure that { 

when { the periodic tracking area updating timer T3412 expires } 
then { UE sends TRACKING AREA UPDATE REQUEST message with EPS update type = "Periodic updating"] 



9.2.3.1.5.2 



Conformance requirements 



References: The conformance requirements covered in the present TC are specified in: 3GPP TS 24.301 clauses 5.3.2, 
5.5.3.2.1, 5.5.3.2.2 and 5.5.3.2.4. 

[TS24.301 clause5.3.2] 

Periodic tracking area updating is used to periodically notify the availability of the UE to the network. The procedure is 
controlled in the UE by the periodic tracking area update timer (timer T3412). The value of timer T3412 is sent by the 
network to the UE in the ATTACH ACCEPT message and can be sent in the TRACKING AREA UPDATE ACCEPT 
message. The UE shall apply this value in all tracking areas of the list of tracking areas assigned to the UE, until a new 
value is received. 

The timer T3412 is reset and started with its initial value, when the UE goes from EMM-CONNECTED to EMM-IDLE 
mode. The timer T3412 is stopped when the UE enters EMM-CONNECTED mode. 

When timer T3412 expires, the periodic tracking area updating procedure shall be started and the timer shall be set to its 
initial value for the next start. 

If the UE is in another state than EMM-REGISTERED.NORMAL-SERVICE when the timer expires the periodic 
tracking area updating procedure is delayed until the UE returns to EMM-REGISTERED.NORMAL-SERVICE. 

The network supervises the periodic tracking area update procedure of the UE by means of the Mobile Reachable timer. 
The Mobile Reachable timer shall be longer than T3412. By default, the Mobile Reachable timer is 4 minutes greater 
than T3412. The network behaviour upon expiry of the Mobile Reachable timer is network dependent, but typically the 
network stops sending paging messages to the UE on the first expiry, and may take other appropriate actions. 

The Mobile Reachable timer shall be reset and started with its initial value, when the MME releases the NAS signalling 
connection for the UE. The Mobile Reachable timer shall be stopped when an NAS signalling connection is established 
for the UE. 

[TS24.301 clause5.5. 3.2.1] 

The periodic tracking area updating procedure is controlled in the UE by timer T3412. When timer T3412 expires, the 
periodic tracking area updating procedure is started. Start and reset of timer T3412 is described in subclause 5.5.3.2. 

[TS24.301 clause5.5. 3.2.2] 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 488 ETSI TS 136 523-1 V8.0.1 (2009-01) 

The UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING 
AREA UPDATE REQUEST message to the MME, 



ii) when the periodic tracking area updating timer T3412 expires; 



After sending the TRACKING AREA UPDATE REQUEST message to the MME, the UE shall start timer T3430 and 
enter state EMM-TRACKING-AREA-UPDATING-INITIATED (see figure 5.5.3.2.2). If timer T3402 is currently 
running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer T341 1. 

In the TRACKING AREA UPDATE REQUEST message the UE shall include a GUTI and the last visited registered 
TAI, the update type indicating the type of the tracking area updating. If the UE's TIN indicates "P-TMSI" the UE shall 
map the valid P-TMSI and RAI into the old GUTI. If a UE in EMM-IDLE mode has uplink user data pending when it 
initiates the tracking area updating procedure, or uplink signalling not related to the tracking area updating procedure, it 
may also set an "active" flag in the TRACKING AREA UPDATE REQUEST message to indicate the request to 
establish the user plane to the network and to keep the NAS signalling connection after the completion of the tracking 
area updating procedure. 

When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an EPS bearer 
context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS bearer contexts are 
active in the UE. 

[TS24.301 clause5.5. 3.2.4] 



Upon receiving a TRACKING AREA UPDATE ACCEPT message, the UE shall stop timer T3430, reset the routing 
area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EUl UPDATED. If the 
message contains a GUTI, the UE shall use this GUTI as new temporary identity for EPS services and shall store the 
new GUTI. If no GUTI was included by the MME in the TRACKING AREA UPDATE ACCEPT message, the old 
GUTI shall be used. If the UE receives a new TAI list in the TRACKING AREA UPDATE ACCEPT message, the UE 
shall consider the new TAJ list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAJ list 
as valid. 



If the TRACKING AREA UPDATE ACCEPT message contained a GUTI, the UE shall return a TRACKING AREA 
UPDATE COMPLETE message to the MME to acknowledge the received GUTI. 

9.2.3.1.5.3 Test description 

9.2.3.1.5.3.1 Pre-test conditions 

System Simulator: 

- Cell 1 (FDD or TDD). 

- Cell 1 belongs to TAI-1 

UE: 
None. 

Preamble: 

- The UE shall be in state EMM-DEREGISTERED. 

Editor's note: The preamble clause should refer to a state according to TS 36.508. 
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9.2.3.1.5.3.2 



Test procedure sequence 



Table 9.2.3.1.5.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is powered up or switched on. 






- 


- 


2 


The UE transmits an ATTACH REQUEST 
message with a PDN CONNECTIVITY 
REQUEST message to request PDN 
connectivity to the default PDN 


— > 


ATTACH REQUEST 






3 


The SS starts an authentication procedure 


<— 


AUTHENTICATION REQUEST 


- 


- 


4 


The UE responds to the authentication 
procedure 


— > 


AUTHENTICATION RESPONSE 


- 


- 


5 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


6 


The UE responds to the NAS security mode 
command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


7 


The SS transmits an ATTACH ACCEPT 
message with GUTI-1 and with the ACTIVATE 
DEFAULT EPS BEARER CQNTEXT 
REQUEST message. The value of the timer 
T3412 in this message is 6minutes. EPS 
Attach result = "EPS only". GUTI = "GUTI-1". 
T3412 value = "6minutes" 


<— 


ATTACH ACCEPT 






8 


The UE transmits an ATTACH COMPLETE 
message with the ACTIVATE DEFAULT EPS 
BEARER CONTEXT ACCEPT message 


— > 


ATTACH COMPLETE 






9 


The SS releases the RRC connection. 






- 


- 


10 


Check: Does during 6 minutes after step 7 the 
UE send TRACKING AREA UPDATE 
REQUEST message after the timer T341 2 
expired. EPS update type = "Periodic 
updating" 


-> 


TRACKING AREA UPDATE 
REQUEST 


1 


P 


11 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


12 


The UE responds to the NAS security mode 
command procedure 


— > 


SECURITY MODE COMPLETE 


- 


- 


13 


The SS sends TRACKING AREA UPDATE 
ACCEPT. EPS update result = "TA only". 
GUTI = "GUTI-2" 


<— 


TRACKING AREA UPDATE 
ACCEPT 






14 


Check: Does the UE send TRACKING AREA 
UPDATE COMPLETE message? 


-> 


TRACKING AREA UPDATE 
COMPLETE 


1 


P 


15 


The SS releases the RRC connection. 






- 


- 


16 


The SS sends Paging message with S-TMSI2 
associated with GUTI-2. 


<— 




- 


- 


17 


Check: Does the UE initiates RRC Connection 
establishment? 


- 




1 


P 



Editor's note: For each test step with transmission of a NAS message, the differences compared with the default 
message contents as defined in 36.508 shall be specified as specific message contents. Then, the related 
information in the procedure description should be removed. 

Editor's note: It is not clear in step 10 if the verdict P is assigned if the UE transmits the TRACKING AREA 

UPDATE REQUEST message at any time in the next 6 minutes, or if the UE transmits 6 minutes another 

test step. 

9.2.3.1.5.3.3 Specific message contents 

Editor's note: See editor's note in previous subclause. 
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9.2.3.2 Combined tracking area updating 
9.2.3.2.1 Combined tracking area update / successful 

9.2.3.2.1 .1 Test Purpose (TP) 
(1) 

with { a combined EPS/IMSI attached UE in state EMM-REGISTERED and EMM-IDLE mode} 
ensure that { 

when { UE enters a tracking area included in the TAI list } 
then { UE does not transmit a TRACKING AREA UPDATE REQUEST message } 
} 

(2) 

with { a combined EPS/IMSI attached UE in state EMM-REGISTERED and EMM-IDLE mode} 
ensure that { 

when { UE enters a tracking area not included in the TAI list } 
then { UE transmits a TRACKING AREA UPDATE REQUEST message with "EPS update type = combined TA/LA 
updating" } 

} 

(3) 

with { UE has sent a combined TRACKING AREA UPDATE REQUEST message } 
ensure that { 

when { UE receives a TRACKING AREA UPDATE ACCEPT message containing a GUTI and/or a mobile 
identity } 

then { UE transmits a TRACKING AREA UPDATE COMPLETE message and enters EMM-REGISTERED state } 
} 

9.2.3.2.1.2 Conformance requirements 

References: The conformance requirements covered in the present TC are specified in: TS 24.301, clauses 5.5.3.1, 
5.5.3.2.2, 5.5.3.2.4, 5.5.3.3.1, 5.5.3.3.2, 5.5.3.3.4.1 and 5.5.3.3.4.2. 

[TS24.301 clause 5.5.3.1] 

The tracking area updating procedure is always initiated by the UE and is used for the following purposes: 

- normal tracking area updating to update the registration of the actual tracking area of a UE in the network; 

[TS24.301 clause 5.5.3.2.2] 

The UE in state EMM-REGISTERED shall initiate the tracking area updating procedure by sending a TRACKING 
AREA UPDATE REQUEST message to the MME, 

i) when the UE detects entering a tracking area that is not in the list of tracking areas that the UE previously 
registered in the MME; 



After sending the TRACKING AREA UPDATE REQUEST message to the MME, the UE shall start timer T3430 and 
enter state EMM-TRACKING-AREA-UPDATING-INITIATED (see figure 5.5.3.2.2). If timer T3402 is currently 
running, the UE shall stop timer T3402. If timer T341 1 is currently running, the UE shall stop timer T341 1. 

In the TRACKING AREA UPDATE REQUEST message the UE shall include a GUTI and the last visited registered 
TAI, the update type indicating the type of the tracking area updating. If the UE's TIN indicates "P-TMSI" the UE shall 
map the valid P-TMSI and RAI into the old GUTI. If a UE in EMM-IDLE mode has uplink user data pending when it 
initiates the tracking area updating procedure, or uplink signalling not related to the tracking area updating procedure, it 
may also set an "active" flag in the TRACKING AREA UPDATE REQUEST message to indicate the request to 
establish the user plane to the network and to keep the NAS signalling connection after the completion of the tracking 
area updating procedure. 
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When the tracking area updating procedure is initiated in EMM-IDLE mode, the UE may also include an EPS bearer 
context status IE in the TRACKING AREA UPDATE REQUEST message, indicating which EPS bearer contexts are 
active in the UE. 

[TS24.301 clause 5.5.3.2.4] 



Upon receiving a TRACKING AREA UPDATE ACCEPT message, the UE shall stop timer T3430, reset the routing 
area updating attempt counter, enter state EMM-REGISTERED and set the EPS update status to EUl UPDATED. If the 
message contains a GUTI, the UE shall use this GUTI as new temporary identity for EPS services and shall store the 
new GUTI. If no GUTI was included by the MME in the TRACKING AREA UPDATE ACCEPT message, the old 
GUTI shall be used. If the UE receives a new TAI list in the TRACKING AREA UPDATE ACCEPT message, the UE 
shall consider the new TAI list as valid and the old TAI list as invalid; otherwise, the UE shall consider the old TAI list 
as valid. 



If the TRACKING AREA UPDATE ACCEPT message contained a GUTI, the UE shall return a TRACKING AREA 
UPDATE COMPLETE message to the MME to acknowledge the received GUTI. 

[TS24.301 clause 5.5.3.3.1] 

Within a combined tracking area updating procedure the messages TRACKING AREA UPDATE ACCEPT and 
TRACKING AREA UPDATE COMPLETE carry information for the tracking area updating and the location area 
updating. 

The combined attach procedure basically follows the normal tracking area updating procedure described in subclause 
5.5.3.2. 

[TS24.301 clause 5.5.3.3.2] 

To initiate a combined tracking area updating procedure the UE sends the message TRACKING AREA UPDATE 
REQUEST to the network, starts timer T3430 and changes to state EMM-TRACKING- AREA-UPDATING- 
INITIATED. The value of the EPS update type IE in the message shall indicate "combined TA/LA updating" unless 
explicitly specified otherwise. 

[TS24.301 clause 5.5.3.3.4.1] 

Depending on the value of the EPS update result IE received in the TRACKING AREA UPDATE ACCEPT message, 
two different cases can be distinguished: 

1) The EPS update result IE value indicates "combined TA/LA": Tracking and location area updating is successful; 



A TRACKING AREA UPDATE COMPLETE message shall be returned to the network if the TRACKING AREA 
UPDATE ACCEPT message contains a GUTI and/or a mobile identity. 

[TS24.301 clause 5.5.3.3.4.2] 

The description for normal tracking area update as specified in subclause 5.5.3.2.4 shall be followed. In addition, the 
following description for location area updating applies. 

The TMSI reallocation may be part of the combined tracking area updating procedure. The TMSI allocated is then 
included in the TRACKING AREA UPDATE ACCEPT message together with the location area identification (LAI). In 
this case the MME shall change to state EMM -COMMON-PROCEDURE-INITIATED and shall start the timer T3450 
as described in subclause 5.4.1. The LAI may be included in the TRACKING AREA UPDATE ACCEPT message 
without TMSI. 

The UE, receiving a TRACKING AREA UPDATE ACCEPT message, stores the received location area identification, 
resets the location update attempt counter, sets the update status to Ul UPDATED and enters MM state MM IDLE. 

How to handle the old TMSI stored in the UE depends on the mobile identity included in the TRACKING AREA 
UPDATE ACCEPT message. 
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- If the TRACKING AREA UPDATE ACCEPT message contains an IMSI, the UE is not allocated any TMSI, 
and shall delete any old TMSI accordingly. 

- If the TRACKING AREA UPDATE ACCEPT message contains a TMSI, the UE shall use this TMSI as new 
temporary identity. The UE shall delete its old TMSI and shall store the new TMSI. In this case, a TRACKING 
AREA UPDATE COMPLETE message is returned to the network to confirm the received TMSI. 

- If neither a TMSI nor an IMSI has been included by the network in the TRACKING AREA UPDATE ACCEPT 
message, the old TMSI, if any is available, shall be kept. 

The network receiving a TRACKING AREA UPDATE COMPLETE message stops timer T3450, changes to state 
EMM-REGISTERED and considers the new TMSI as valid. 

9.2.3.2.1.3 Test description 

9.2.3.2.1.3.1 Pre-test conditions 

System Simulator: 

- Cell 1, Cell 2 and Cell 4 

- Cell 1 belongs to TAI-1, Cell2 belongs to TAI-2 and Cell4 belongs to TAI-4. 

- Cell A (UTRA FDD or UTRA TDD or GSM or CDMA2000). 

UE: 

- The test USIM contains GUTI-1 and a valid TAI-1 for EPS service, and EPS update status is "EUl: 
UPDATED". 

The test USIM contains TMSI-1 and a valid LAI-1 for CS service, and Location update status is " Ul: 
UPDATED". 

Preamble: 

The UE is in state switched OFF (state 1) according to [18]. 
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9.2.3.2.1.3.2 



Test procedure sequence 



Table 9.2.3.2.1.3.2-1: Main Behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 




The following messages are sent and shall be 
received on cell 1 . 


- 


- 


- 


- 


1 


Set the cell type of cell 1 to the "Serving cell". 
Set the cell type of cell 2 to the "Suitable 
neighbour cell". Set the cell type of cell 4 to the 
"Suitable neighbour cell". 










2 


The UE is powered up or switched on. 


- 


- 


- 


- 


3 


The UE transmits an ATTACH REQUEST 
message with a PDN CONNECTIVITY 
REQUEST message to request PDN 
connectivity to the default PDN. 


— > 


ATTACH REQUEST 






4 


The SS starts an authentication procedure. 


<— 


AUTHENTICATION REQUEST 


- 


- 


5 


The UE responds to the authentication 
procedure. 


-> 


AUTHENTICATION RESPONSE 


- 


- 


6 


The SS starts a NAS security mode command 
procedure to perform NAS integrity protection. 


<— 


SECURITY MODE COMMAND 


- 


- 


7 


The UE responds to the NAS security mode 
command procedure. 


— > 


SECURITY MODE COMPLETE 


- 


- 


8 


The SS transmits ATTACH ACCEPT message 
including a ACTIVATE DEFAULT EPS 
BEARER CONTEXT REQUEST message. 
EPS Attach result = "combined EPS/IMSI 
attach" 


<— 


ATTACH ACCEPT 






9 


The UE transmits an ATTACH COMPLETE 
message including an ACTIVATE DEFAULT 
EPS BEARER CONTEXT ACCEPT message. 


— > 


ATTACH COMPLETE 






10 


The SS releases the RRC connection. 


- 


- 


- 


- 


11 


Set the cell type of cell 1 to the "non-Suitable 
cell". Set the cell type of cell 2 to the "Serving 
cell" 










12 


Check: Does the UE transmit a TRACKING 
AREA UPDATE REQUEST message in the 
next SOseconds? 






1 


F 


13 


Check: Does the test results of CALL generic 
procedure [18] indicate that the UE is in E- 
UTRA EMM-REGISTERED state on cell 2 with 
PagingUE-ldentity = S-TMSI1 ? 






1 






The following messages are sent and shall be 
received on cell 4. 


- 


- 


- 


- 


14 


Set the cell type of cell 2 to the " non-Suitable 
cell ". Set the cell type of cell 4 to the " Serving 
cell" 










15 


Check: Does the UE transmit a combined 
TRACKING AREA UPDATE REQUEST 
message as specified? 


— > 


TRACKING AREA UPDATE 
REQUEST 


2 


P 


16 


The SS sends TRACKING AREA UPDATE 
ACCEPT message. Note: GUTI present and 
MS identity not present 


<— 


TRACKING AREA UPDATE 
ACCEPT 






17 


Check: Does the UE transmit a TRACKING 
AREA UPDATE COMPLETE message. 


— > 


TRACKING AREA UPDATE 
COMPLETE 


2,3 


P 


18 


The SS releases the RRC connection. 


- 


- 


- 


- 


19 


Check: Does the test results of CALL generic 
procedure [18] indicate that the UE is in E- 
UTRA EMM-REGISTERED state on cell 4 with 
PagingUE-ldentity = S-TMSI2? 






2 






The following messages are sent and shall be 
received on cell 1 . 


- 


- 


- 


- 


20 


Set the cell type of cell 4 to the " non-Suitable 
cell ". Set the cell type of cell 1 to the " Serving 
cell" 










21 


Check: Does the UE transmit a combined 


— > 


TRACKING AREA UPDATE 


2 


P 
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TRACKING AREA UPDATE REQUEST 
message? 




REQUEST 






22 


The SS sends TRACKING AREA UPDATE 
ACCEPT message. Note: GUT! not present 
and IVIS identity present 


<— 


TRACKING AREA UPDATE 
ACCEPT 






23 


Check: Does the UE send TRACKING AREA 
UPDATE COMPLETE message. 


— > 


TRACKING AREA UPDATE 
COMPLETE 


2,3 


P 


24 


The SS releases the RRC connection. 


- 


- 


- 


- 


25 


The SS pages the UE with S-TI\/ISI2 
associated with GUTI-2 (or TMSI-3) for non- 
EPS service. 










26 


Check: Does the UE initiates a connection on 
cell A? (FFS) 


- 


- 


2 


P 



Editor's note: The definitions for "Non-Suitable cell", "Suitable neighbour cell" and "Serving cell" are FFS and 
should be specified in TS36.508. 

Note 1 : It is assumed in the test procedure sequence that the UE initially has a vahd GUTI. 

Note 2: NAS security procedures are not checked in this TC. 



9.2.3.2.1.3.3 



Specific message contents 



Table 9.2.3.2.1.3.3-1 : Message TRACKING AREA UPDATE REQUEST (step 15, Table 9.2.3.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-27 | 


Information Element 


Value/Remark 


Comment 


Condition 


MS network capability 


(FFS) 


Cf TS 24.008 
clause 10.5.5.12 




EPS update type 


001 


"combined TA/LA 
updating" 

The combined 
EPS attach 
procedure is used 
by a CS fallback 
capable UE to 
attach for both 
EPS and non- 
EPS services. 




Spare half octet 


0000 






Old GUTI 


GUTI-1 


Old GUTI is 
included by UE if 
if valid, IMSI 
otherwise. 




NAS key set identifierASME 


FFS 






NAS key set identifiersesN 


FFS 






Last visited registered TAI 


TAI-2 


If available, the 
last TAI is 
included by UE 
and will be used 
to establish a 
good list of TAIs 
in subsequent 
ATTACH 
ACCEPT 
message. 




EPS bearer context status 


Not checked 






Old P-TMSI signature 


Not present 






NonceuE 


FFS 






Old LAI (FFS) 


LAI-1 






TMSI status (FFS) 


1 


"valid TMSI 
available" 
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Table 9.2.3.2.1.3.3-2: Message TRACKING AREA UPDATE ACCEPT (step 16, Table 9.2.3.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-24 


Information Element 


Value/Remark 


Comment 


Condition 


EPS update result 


001 


"combined TA/LA" 




Spare half octet 


0000 






T3412value 


Not present 






GUT! 


GUTI-2 


This IE may be 
included to assign 
a new GUTI 




TAI list 








Length of tracking area identity list contents 


00001000 


8 octets 




Number of elements 


000001 


1 element 




Type of list 


000 


One PLMN with 

non-consecutive 

TACs 




Partial tracking area identity list 


PLMN = PLMN1 
TAG 1 = TAG-4 


TAI-4 




EPS bearer context status 


Same value as in 
TRAGKING AREA 
UPDATE REQUEST 
message 






ISR indication 


FFS 






LAI 


LAI-2 






IVIS identity 


Not Present 


SS doesn't 
provide TMSI 




T3402 value 


Not present 






Equivalent PLMNs 


Not present 






EMM cause (FFS) 


Not present 
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Table 9.2.3.2.1.3.3-3: Message TRACKING AREA UPDATE REQUEST (step 21, Table 9.2.3.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-27 


Information Element 


Value/Remark 


Comment 


Condition 


MS network capability 


(FFS) 


Cf TS 24.008 
clause 10.5.5.12 




EPS update type 


001 


"combined TA/LA 
updating" 
The combined 
EPS attach 
procedure is used 
by a CS fallback 
capable UE to 
attach for both 
EPS and non- 
EPS services. 




Spare half octet 


0000 






Old GUT! 


GUTI-2 


Old GUT! is 
included by UE if 
if valid, IMSI 
otherwise. 




NAS key set identifierASME 


FFS 






NAS key set identifierSGSN 


FFS 






Last visited registered TAI 


TAI-4 


If available, the 
last TAI is 
included by UE 
and will be used 
to establish a 
good list of TAIs 
in subsequent 
ATTACH 
ACCEPT 
message. 




EPS bearer context status 


Not checked 






Old P-TMSI signature 


Not present 






NonceUE 


FFS 






Old LAI (FFS) 


LAI-2 






TMSI status (FFS) 


1 


"valid TMSI 
available" 
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Table 9.2.3.2.1.3.3-4: Message TRACKING AREA UPDATE ACCEPT (step 22, Table 9.2.3.2.1.3.2-1) 



Derivation path: 36.508 table 4.7.2-24 


Information Element 


Value/Remark 


Comment 


Condition 


EPS update result 


001 


"combined TA/LA" 




Spare half octet 


0000 






T3412value 


Not present 






GUT! 


Not present 


The SS doesn't 
assign a new 
GUTI 




TAI list 








Length of tracking area identity list contents 


00001000 


8 octets 




Number of elements 


000001 


1 element 




Type of list 


000 


One PLMN with 

non-consecutive 

TACs 




Partial tracking area identity list 


PLMN = PLMN1 
TAG 1 = TAG-1 


TAI-1 




EPS bearer context status 


Same value as in 
TRAGKING AREA 
UPDATE REQUEST 
message 






ISR indication 


FFS 






LAI 


Not present 






IVIS identity 


TMSI-3 


SS provides a 
new TMSI 




T3402 value 


Not present 






Equivalent PLMNs 


Not present 






EMM cause (FFS) 


Not present 







9.3 
9.3.1 

9.3.1.1 
9.3.1.1.1 

(1) 



EMM connection management procedures (SI mode only) 
Service Request Procedure 

Service Request initiated by UE for user data 
Test Purpose (TP) 



with { UE in EMM-REGISTRED state and EMM- IDLE mode } 
ensure that { 

when { UE has user data pending } 

then { UE sends a SERVICE REQUEST message and enters EMM-REGISTERED state and EMM-CONNECTED mode 



9.3.1.1.2 



Conformance requirements 



The conformance requirements covered in the current TC are specified in: 3GPP TS 24.301 clause 5.1.2, 5.6.1.1, 5.6.1.2 
and 5.6.1.3. 

[TS 24.301 clause 5.1.2] 

The service request procedure can only be initiated if no UE initiated EMM specific procedure is ongoing. 

[TS 24.301 clause 5.6.1.1] 

The purpose of the service request procedure is to transfer the EMM mode from EMM-IDLE to EMM-CONNECTED 
mode and establish the radio and S 1 bearers when uplink user data is to be sent. 
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This procedure is used when: 

the UE or the network has user data pending and the UE is in EMM-IDLE mode; 
The UE shall invoke the service request procedure when: 



b) the UE, in EMM-IDLE or EMM-CONNECTED mode, has pending user data to be sent and no radio bearer is 
established. 

[TS 24.301 clause 5.6.1.2] 

The UE initiates the service request procedure by sending a SERVICE REQUEST message to the MME, starts the timer 
T3417, and enters the state EMM-SERVICE-REQUEST-INITIATED and EMM-CONNECTED mode. 

[TS 24.301 clause 5.6.1.3] 

The UE shall treat the indication from the lower layers that the user plane radio bearer is set up as successful completion 
of the procedure. 

Upon successful completion of the procedure, the UE shall stop the timer T3417 and enter the state EMM- 
REGISTERED. 

9.3.1.1.3 Test description 

9.3.1.1.3.1 Pre-test conditions 

System Simulator: 

- CeUl 

UE: 

- USIM inserted/present, K, CK, IK stored. 

Editor's note: is there any different with other test cases on this aspect? 

Preamble: 

The UE is in state Registered, Idle Mode according to [18]. 
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9.3.1.1.3.2 



Test procedure sequence 



Table 9.3.1.1.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


Force the UE to initiate transmission of uplink 
data, (Note 1) 


- 


- 


- 


- 


2 


Check: Does the UE transmit a SERVICE 
REQUEST message? 


— > 


SERVICE REQUEST 


1 


P 


3 


The SS performs a radio bearer establishment 
procedure. (Note 2) 


- 


- 


- 


- 


4 


Check: Does the UE establish an RRC 
connection? (Note 2) 


- 


- 


1 


P 


Note 1 : This could be done by e.g. MMI or by AT command. 

Note 2: After a correct SERVICE MESSAGE is received then the SS performs the Radio Bearer Establishment 
procedure. The UE transmission of the RRCConnectionReconfigurationComplete message indicates the 
completion of the radio bearer establishment procedure and that the UE has changed EMM mode from 
EMM-IDLE to EMM-CONNECTED. 



9.3.1.1.3.3 
FFS 



Specific message contents 



9.3.1.2 
9.3.1.2.1 

(1) 



Service Request initiated by UE for uplink signalling 
Test Purpose (TP) 



with { UE in EMM-REGISTERED state and EMM- IDLE mode } 
ensure that { 

when { UE has uplink signalling pending } 

then { UE sends a SERVICE REQUEST message and enters EMM-REGISTERED state and EMM-CONNECTED mode 



9.3.1.2.2 



Conformance requirements 



The conformance requirements covered in the current TC are specified in: 3GPP TS 24.301 clause 5.6.1.1, 5.6.1.2 and 
5.6.1.3. 

[TS 24.301 clause 5.6.1.1] 



The UE shall invoke the service request procedure when: 



c) the UE, in EMM-IDLE mode, has uplink signalling pending. 



[TS 24.301 clause 5.6.1.2] 

The UE initiates the service request procedure by sending a SERVICE REQUEST message to the MME, starts the timer 
T3417, and enters the state EMM-SERVICE-REQUEST-INITIATED. 



[TS 24.301 clause 5.6.1.3] 

The UE shall treat the indication from the lower layers that the user plane radio bearer is set up as successful completion 
of the procedure. 
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Upon successful completion of the procedure, the UE shall stop the timer T3417 and enter the state EMM- 
REGISTERED. 



9.3.1.2.3 




9.3.1.2.3.1 




System SirriL 


lator 


- Cell 1 




UE: 




None. 





Test description 
Pre-test conditions 



Preamble: 

- The UE is in state Registered, Idle Mode (State 2) according to [18]. 



9.3.1.2.3.2 



Test procedure sequence 



Table 9.3.1.2.3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The operator initiates the activation of a new 
EPS bearer context based on the default PDN, 
in order to initiate transmission of uplink 
signalling (Note 1). 










2 


Check: Does UE transmit a SERVICE 
REQUEST message? 


— > 


SERVICE REQUEST 


1 


P 


3 


The UE transmits a BEARER RESOURCE 
ALLOCATION REQUEST message. 


— > 


BEARER RESOURCE 
ALLOCATION REQUEST 


- 


- 


4 


The SS transmits a ACTIVATE DEDICATED 
EPS BEARER CONTEXT REQUEST 
message activating a new EPS bearer context. 

This message is included in a 
RRCConnectionReconfiguration message to 
setup the new radio bearer associated with the 
dedicated EPS bearer context activated by the 
NAS message. 


<— 


ACTIVATE DEDICATED EPS 
BEARER CONTEXT REQUEST 






5 


Check: Does UE transmit a 
RRCConnectionReconfigurationComplete 
message? (Note 2) 






1 


P 


6 


The UE transmits an ACTIVATE DEDICATE 
EPS BEARER CONTEXT ACCEPT message. 


— > 


ACTIVATE DEDICATE EPS 
BEARER CONTEXT ACCEPT 


- 


- 


Note 1 : This can be done using MMI or an AT command (FFS). 

Note 2: After a correct SERVICE REQUEST message is received then the SS performs the Radio Bearer 

Establishment procedure. The UE transmission of the RRCConnectionReconfigurationComplete message 
indicates the completion of the radio bearer establishment procedure and that the UE has changed EIVIM 
mode from EMM-IDLE to EMM-CONNECTED. 



9.3.1.2.3.3 
FFS. 



Specific message contents 
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9.4 NAS Security 

9.4.1 Integrity protection: Correct functionality of EPS NAS integrity 
algorithm (SN0W3G) 

9.4.1.1 Test Purpose (TP) 
(1) 

with { succesful completion of EPS authentication and key agreement (AKA) procedure } 
ensure that { 

when { UE receives a an integrity protected SECURITY MODE COMMAND message instructing to start 
integrity protection using algorithm SN0W3G } 

then { UE transmits an integrity protected SECURITY MODE COMPLETE using SN0W3G and starts 
applying the NAS Integrity protection in both UL and DL } 

(2) 

with { Integrity protection succesfull started by executing Security Mode Procedure} 
ensure that { 

when { UE receives an IDENTITY REQUEST message without integrity protected } 
then { UE foes not transmit an IDENTITY RESPONSE message } 
} 

9.4.1.2 Conformance requirements 

References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 4.4.3.1, 
4.4.3.2, 5.4.3.1, 5.4.3.2 and 5.4.3.3. 

[TS 24.301, clause 4.4.3.1] 

Integrity protected signalling is mandatory for the NAS messages once a valid NAS security context exists and the NAS 
security mode control procedure has been successfully completed in the network and the UE. Integrity protection of all 
NAS signalling messages is the responsibility of the NAS layer. It is the network which activates integrity protection. 

[TS 24.301, clause 4.4.3.2] 

Once integrity protection is activated, the receiving EMM or ESM entity in the UE shall not process any NAS 
signalling messages unless they have been successfully integrity checked by the NAS layer. If NAS signalling 
messages, having not successfully passed the integrity check, are received, then the NAS layer in the UE shall discard 
that message. If any NAS signalling message is received, as not integrity protected even though the integrity protection 
has been activated in the UE by the network, then the NAS layer shall discard this message. 

[TS 24.301, clause 5.4.3.1] 

The purpose of the NAS security mode command (SMC) procedure is to take the new key set into use, initialise and 
start NAS signalling security between the UE and the MME, which performs integrity and replay protection as well as 
enciphering and deciphering of NAS signalling messages. 

Editor's note: It is FES whether the SMC procedure can be combined or concatenated with the attach and tracking 
area update procedures for optimisation purposes. 

[TS 24.301, clause 5.4.3.2] 

The MME initiates the NAS security mode setup command procedure by sending a SECURITY MODE COMMAND 

message to the UE and starting timer T3460. 

The MME shall integiity protect the SECURITY MODE COMMAND message with the NAS integrity key based on 
Kasme indicated by the KSIasme indicated in the message. 



The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to 
NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security 
capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed NONCEUE if the UE 
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included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set 
Identifier (KSIasme or KSIsgsn)- 

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message. 

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it 
is also be supported for AS. 

[TS 24.301, clause 5.4.3.3] 

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode 
command can be accepted or not. This is done by performing the integrity check of the message and by checking that 
the received UE security capabilities and the received UE nonce have not been altered compared to what the UE 
provided in the initial layer 3 message that triggered this procedure. 

If the security mode command can be accepted and the KSIasme was included in the SECURITY MODE COMMAND 
message, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS 
integrity algorithm and the NAS integrity key based on the Kasme indicated by the KSIasme. If the SECURITY MODE 
COMMAND message includes KSIsgsn, MME nonce and UE nonce, the UE shall generate K'asme from both nonces as 
indicated in 3GPP TS 33.401 [11] to check whether the SECURITY MODE COMMAND can be accepted or not. If the 
MME selected a NAS ciphering algorithm different from the "null ciphering algorithm", the UE shall cipher the 
SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key 
based on the Kasme indicated by the KSIasme or fresh K'asme- 

From now on the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering 
and NAS integrity algorithms. 

If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall 
include its IMEISV in the SECURITY MODE COMPLETE message. 



9.4.1.3 


Test description 


9.4.1.3.1 


Pre-test conditions 


System Simulator: 




- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.4.1.3.2 



Test procedure sequence 



Table 9.4.1 .3.2-1: Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


The UE transmits an ATTACH REQUEST 
message 


— > 


ATTACH REQUEST 


- 


- 


3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






5 


The SS transmits a NAS SECURITY MODE 
COMMAND message to activate NAS security. 
SnowSG is algorithm for integrity protection. It 
is integrity protected. 


<— 


SECURITY MODE COMMAND 






6 


Check: does the UE transmit a NAS 
SECURITY MODE COMPLETE message and 
establish the initial security configuration? 


— > 


SECURITY MODE COMPLETE 


1 


P 


7 


The SS transmits with an ATTACH ACCEPT 
message 


<— 


ATTACH ACCEPT 


- 


- 


8 


The UE transmits an ATTACH COMPLETE 
message 


— > 


ATTACH COMPLETE 


- 




9 


The SS Transmits an IDENTITY REQUEST 
message [Integrity protected] 


<- 


IDENTITY REQUEST 


- 


- 


10 


Check: does the UE transmit an IDENTIY 
RESPONSE message [Integrity Protected]? 


-> 


IDENTITY RESPONSE 


1 


P 


11 


The SS Transmits an IDENTITY REQUEST 
message [not Integrity protected] 


<- 


IDENTITY REQUEST 


- 


- 


12 


Check: does the UE transmits an IDENTIY 
RESPONSE message within the next 5 
seconds? 


-> 


IDENTITY RESPONSE 


2 


F 



Editor's note: The "establishment of initial security configuration" is not described by any action neither in the TP, 
nor in the conformance requirements. If these statements are purely explanatory, they should be indicated 
as notes or removed. 

Editor's note: Does " [Security protected] " mean that it is PES if the message is security protected, or shall it be 
security protected? 



9.4.1.3.3 



Specific message contents 
Table 9.4.1 .3.3-1 : SECURITY MODE COMMAND (Step 5) 



Derivation path: 36.508 table 4.7.2-1 9 | 


Information Element 


Value/Remark 


Comment 


Condition 


Selected NAS security algorithms 








- Type of integrity protection algorithm 


001 


EPS integrity 
algorithm 128- 
EIA1[SN0W3G] 





9.4.2 Integrity protection: Correct functionality of EPS NAS integrity 
algorithm (AES) 



9.4.2.1 



Test Purpose (TP) 



(1) 

with { succesful completion of EPS authentication and key agreement (AKA) procedure 
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ensure that { 

when { UE receives an integrity protected SECURITY MODE COMMAND message, to start integrity 
protection using algorithm AES } 

then { UE sends SECURITY MODE COMPLETE, integrity protected with AES and starts applying the NAS 
Integrity protection in both UL and DL} 

(2) 

with { Integrity protection succesfull started by executing Security Mode Procedure} 
ensure that { 

when { UE receives a IDENTITY REQUEST message {requested identification parameter is not IMSI) , 
without integrity protected } 

then { UE Does not transmit IDENTITY Response} 
} 

9.4.2.2 Conformance requirements 
Same Conformance requirements as in clause 9.4.1.2 

9.4.2.3 Test description 



9.4.2.3.1 Pre-test conditions 
Same Pre-test conditions as in clause 9.4.1.3.1 

9.4.2.3.2 Test procedure sequence 

Same Test procedure sequence as in table 9.4.1.3.2.1, except the integrity protection algorithm is AES. 

9.4.2.3.3 Specific message contents 

Table 9.4.2.3.3-1 : SECURITY MODE COMMAND (Step 6 ) 



Derivation path: 36.508 table 4.7.2-1 9 


Information Element 


Value/Remark 


Comment 


Condition 


Selected NAS security algorithms 
- Type of integrity protection algorithm 


010 


EPS integrity 
algorithm 128- 
EIA2 (AES) 





9.4.3 Ciphering and Decipirering: Correct functionality of EPS NAS 
encryption algoritirm (SN0W3G) 



9.4.3.1 



Test Purpose (TP) 



(1) 

with { succesful completion of EPS authentication and key agreement (AKA) procedure } 
ensure that { 

when { UE receives a SECURITY MODE COMMAND instructing to start ciphering using algorithm SN0W3G 
then { UE sends a SECURITY MODE COMPLETE message ciphered with SN0W3G and starts applying the 
NAS ciphering in both UL and DL} 



9.4.3.2 



Conformance requirements 



References: The conformance requirements covered in the current TC are specified in: TS 24.301 clause 5.4.3.1, 5.4.3.2 
and 5.4.3.3. 

[TS 24.301, clause 5.4.3.1] 

The purpose of the NAS security mode command (SMC) procedure is to take the new key set into use, initialise and 
start NAS signalling security between the UE and the MME, which performs integrity and replay protection as well as 
enciphering and deciphering of NAS signalling messages. 
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Editor's note: It is FFS whether the SMC procedure can be combined or concatenated with the attach and tracking area 
update procedures for optimisation purposes. 

[TS 24.301, clause 5.4.3.1] 

The MME initiates the NAS security mode setup command procedure by sending a SECURITY MODE COMMAND 
message to the UE and starting timer T3460. 

The MME shall integrity protect the SECURITY MODE COMMAND message with the NAS integrity key based on 
Kasme indicated by the KSIasme indicated in the message. 



The MME shall include the replayed security capabilities of the UE (including the security capabilities with regard to 
NAS, RRC and UP (user plane) ciphering as well as NAS, RRC integrity, and other possible target network security 
capabilities, i.e. UTRAN/GERAN if UE included them in the message to network), the replayed NONCEUE if the UE 
included it in the message to the network, the selected NAS ciphering and integrity algorithms and the Key Set 
Identifier (KSIasme or KSIsgsn). 

Additionally, the MME may request the UE to include its IMEISV in the SECURITY MODE COMPLETE message. 

NOTE: The AS and NAS security capabilities will be the same, i.e. if the UE supports one algorithm for NAS it 
is also be supported for AS. 

[TS 24.301, clause 5.4.3.3] 

Upon receipt of the SECURITY MODE COMMAND message, the UE shall check whether the security mode 
command can be accepted or not. This is done by performing the integrity check of the message and by checking that 
the received UE security capabilities and the received UE nonce have not been altered compared to what the UE 
provided in the initial layer 3 message that triggered this procedure. 

If the security mode command can be accepted and the KSIasme was included in the SECURITY MODE COMMAND 
message, the UE shall send a SECURITY MODE COMPLETE message integrity protected with the selected NAS 
integrity algorithm and the NAS integrity key based on the Kasme indicated by the KSIasme- If the SECURITY MODE 
COMMAND message includes KSIsgsn^ MME nonce and UE nonce, the UE shall generate K'asme from both nonces as 
indicated in 3GPP TS 33.401 [1 1] to check whether the SECURITY MODE COMMAND can be accepted or not. If the 
MME selected a NAS ciphering algorithm different from the "null ciphering algorithm", the UE shall cipher the 
SECURITY MODE COMPLETE message with the selected NAS ciphering algorithm and the NAS ciphering key 
based on the Kasme indicated by the KSIasme or fresh K'asme- 

From now on the UE shall cipher and integrity protect all NAS signalling messages with the selected NAS ciphering 
and NAS integrity algorithms. 

If the MME indicated in the SECURITY MODE COMMAND message that the IMEISV is requested, the UE shall 
include its IMEISV in the SECURITY MODE COMPLETE message. 

Test description 

Pre-test conditions 



9.4.3.3 




9.4.3.3.1 




System Simi 


ilator: 


- Cell 1 




UE: 




None. 





Preamble: 

The UE is in state Switched OFF (state 1) according to [18]. 
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9.4.3.3.2 



Test procedure sequence 



Table 9.4.3.3.2-1 : Main behaviour 



St 


Procedure 


Message Sequence 


TP 


Verdict 




U-S 


Message 


1 


The UE is switched on. 


- 


- 


- 


- 


2 


The UE transmits an ATTACH REQUEST 
message 


— > 


ATTACH REQUEST 


- 


- 


3 


The SS transmits an AUTHENTICATION 
REQUEST message to initiate the EPS 
authentication and AKA procedure. 


<— 


AUTHENTICATION REQUEST 






4 


The UE transmits an AUTHENTICATION 
RESPONSE message and establishes mutual 
authentication. 


— > 


AUTHENTICATION RESPONSE 






5 


The SS transmits a SECURITY MODE 
COMMAND message to activate MAS security. 
SnowSG is ciphering algorithm. 


<— 


SECURITY MODE COMMAND 






6 


Check: does the UE transmit a SECURITY 
MODE COMPLETE message ciphered with 
SNOWSG and establish the initial security 
configuration? 


--> 


SECURITY MODE COMPLETE 


1 


P 


7 


The SS transmits with an ATTACH ACCEPT 
message 


<— 


ATTACH ACCEPT 


- 


- 


8 


The UE transmits an ATTACH COMPLETE 
message 


— > 


ATTACH COMPLETE 


- 




9 


The SS Transmits an IDENTITY REQUEST 
message [Ciphered] 


<- 


IDENTITY REQUEST 


- 


- 


10 


Check: does the UE transmit an IDENTIY 
RESPONSE message [Ciphered]? 


-> 


IDENTITY RESPONSE 


1 


P 



Editor's note: The "establishment of initial security configuration" is not described by any action neither in the TP, 
nor in the conformance requirements. If these statements are purely explanatory, they should be indicated 
as notes or removed. 

Editor's note: Does "[Ciphered]" mean that it is FFS if the message is ciphered, or shall it be ciphered? 



9.4.1.3.3 



Specific message contents 
Table 9.4.1 .3.3-1 : SECURITY MODE COMMAND (Step 5) 



Derivation path: 36.508 table 4.7.2-1 9 | 


Information Element 


Value/Remark 


Comment 


Condition 


Selected NAS security algorithms 








- Type of ciphering algorithm 


001 


EPS encryption 
algorithm 128- 
EEA1 [SN0W3GJ 





9.4.4 Ciphering and Decipinering: Correct functionality of EPS NAS 
encryption algoritlim (AES) 



9.4.4.1 



Test Purpose (TP) 



(1) 

with { succesful completion of EPS authentication and key agreement (AKA) procedure } 
ensure that { 

when { UE receives a SECURITY MODE COMMAND, to start encryption using algorithm AES} 
then { UE sends SECURITY MODE COMPLETE, encrypted with AES and starts applying the NAS 
encryption in both UL and DL } 
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9.4.4.2 Conformance requirements 
Same Conformance requirements as in clause 9.4.3.2 

9.4.4.3 Test description 

9.4.4.3.1 Pre-test conditions 
Same Pre-test conditions as in clause 9.4.3.3.1 

9.4.4.3.2 Test procedure sequence 

Same Test procedure sequence as in Table 9.4.3.3.2-1, except the integrity ciphering algorithm is AES. 

9.4.4.3.3 Specific message contents 

Table 9.4.1 .3.3-1 : SECURITY MODE COMMAND (Step 6) 



Derivation path: 36.508 table 4.7.2-1 9 


Information Element 


Value/Remark 


Comment 


Condition 


Selected NAS security algorithms 
- Type of ciphering algorithm 


002 


EPS encryption 
algorithm 128- 
EEA2 (AES) 
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10 EPS Session Management 
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1 1 General Tests 



£75/ 



3GPP TS 36.523-1 version 8.0.1 Release 8 510 ETSI TS 136 523-1 V8.0.1 (2009-01) 



1 2 Interoperability Radio Bearer Tests 
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